Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

This section describes the process for migrating from Syndeia Cloud (SC) 3.5 SP2 to Syndeia Cloud 3.6. In the remainder of this document, Syndeia 3.5 implies Syndeia 3.5 SP2.

Overview

Please read the following carefully before proceeding further.

(1) Starting Point: The starting point of the migration process is Syndeia Cloud 3.5 SP2. If you are currently running 3.5 / 3.5 SP1, please first upgrade to 3.5 SP2 then return here. The process is described in Upgrades and Migration

(2) Estimated Time: The estimated time to complete the migration procedure, including build upload (at 6Mbit/s+) but not including original server(s) cloning time, is ~2-3 hours.

(3) Approach: The overall approach for the upgrade process is as follows.

  • Stages 1-2 – The existing Syndeia 3.5 SP2 environment running in production is cloned to create a new environment that is the basis for Syndeia Cloud 3.6. Syndeia admins should make the Syndeia Cloud 3.5 SP2 production deployment unavailable to Syndeia users before cloning. Syndeia 3.5 SP2 production server can be brought back online after cloning but any data created in it after cloning will not be migrated. This approach is taken to ensure that the existing Syndeia Cloud 3.5 SP2 deployment is always available as a golden starting point for the migration process.

  • Stages 3-8 – Syndeia Cloud 3.6 installs are downloaded, services are started, and an upgrade is performed in the cloned environment. Data is verified. The cloned environment is now the new Syndeia Cloud 3.6-based production environment.

(4) Linux CentOS EoL: SC 3.5 was released against RHEL/CentOS 7.X. On Dec. 2020, the CentOS Enterprise Linux project (acquired by RH in 2014) was unilaterally redefined as “CentOS Stream” and is no longer based off the stable branch of RHEL but instead off of Fedora (which is deemed the upstream branch of RH OS-es) (see this for more information). As such, CentOS Enterprise Linux 7.9- the last maintenance release for v7, will reach EoL on 30-June-2024 (the same date as that of RHEL 7).

  • For those using RHEL8, no migration is required

  • For those using RHEL7, please follow RH’s documentation on how to upgrade to RHEL8

  • For those still using CentOS (7 or 8), it is recommended to migrate to Alma Linux. Alma Linux is a binary-compatible version of RHEL that was created by CloudLinux to fill this void along with by-laws to prevent such future corporate takeovers. A migration document is beyond the scope of this document but AlmaLinux has put together a tool and a guide to assist with this transition: See Migrate CentOS 7 to AlmaLinux 8

(info) You do not need to upgrade / migrate CentOS to upgrade to SC 3.6, however it is recommended to do so before the EoL date to ensure you continue to have access to yum (now dnf) repository downloads & security updates (IF mandated).

The Syndeia Cloud 3.5 → 3.6 migration process has the following 6 stages.

NOTE: The pages above have been written from the standpoint of a *NIX deployment running commands in a bash shell ((warning) NOT sh, dash, ksh, or zsh, they share many similar syntax features but are all subtly different!).
For a Windows deployment, the process is identical, except please keep the following rules in mind:

  1. Where it says bash and/or "shell", please use the Cygwin Terminal (which runs bash).
    (info) Note, most .bat tools should be able to run from the Cygwin Terminal, the ONE exception is if you need to run gremlin.bat, which seems to (currently) only work from Windows CMD.EXE

  2. Where it says .sh substitute in .bat. EXCEPT for ALL Intercax-provided scripts.

  3. For the main SC JG setup and the SC setup scripts, use the _windows suffixed scripts instead.

  4. For any component (Cassandra, JanusGraph, etc.) that requires a command, script or executable to be run (ex: cqlsh, gremlin.sh/ gremlin.bat , etc.), ensure you are first cd -ed in the bin directory for that component, ex: Cassandra = cd /opt/apache-cassandra-current/bin , JanusGraph = cd /opt/janusgraph-current/bin ((lightbulb) Tip: if you don’t like doing this, you can add each to your Windows' System PATH environment variable)

  5. Ignore any commands to cd /etc/systemd/system beforehand.

  6. Where it says systemctl substitute in Windows NT SCM’s sc.exe

  7. Where it says systemctl restart ... substitute in sc.exe stop ... followed by sc.exe start ... back to back

  8. Where it says systemctl enable substitute in sc.exe config start= delayed-start

  9. Where it says journalctl, open the raw log file instead

  10. Where it says ln -nfs, use winln -fs (and (warning) make sure the original symlink is deleted first if you are updating it or you will get an error)

  11. Ignore any commands to create any groups or users (this is typically not done in a Windows environment, except for hardening)

  12. Ignore any sudo or sudo -u ... command prefixes.

  • No labels