Preparation


Cameyo can help facilitate a failover process with BYO Azure.  It is assumed you have a persistent server and at least one elastic cluster.  If Azure fails in one region, your Cameyo apps can be directed to an elastic cluster in another region, provided you have taken these steps in the Cameyo portal beforehand.  In the following example, the persistent server and elastic cluster are in US East 2.   We shall prepare an elastic cluster in US West to have for recovery in the event of an Azure failure in US East 2.


  1. Click the elastic cluster you wish to duplicate to another region.

    A screenshot of a computer

Description automatically generated

  2. Click the icon to Duplicate the cluster.

    A green circle with black text

Description automatically generated
    You will be taken to the page of the duplicated cluster.

  3. Rename your duplicated cluster from “copy” to something meaningful.

    A close up of a logo

Description automatically generated

  4. Change Region to the desired failover location.

    A yellow box with black text

Description automatically generated


  5. If the new region is in a different VNET, use !CLOUDVPC and !CLOUDSUBNET PowerTags to define the appropriate values before any servers are created in the new cluster.
    A screen shot of a computer

Description automatically generated


  6. In the address bar, add /maint and <Enter> to start the creation of the necessary Dynamic snapshot used as the Baseline snapshot for elastic servers in the new elastic cluster.



    You will see this message:


    Creating the Dynamic snapshot in the new region may take 60-90 minutes.
    When the new Dynamic snapshot is created, your persistent server will show an additional Dynamic snapshot.

    A screenshot of a computer

Description automatically generated

    In this case, you can see that the Dynamic snapshot with the longer red arrow pointing to it has a newer date than the Dynamic snapshot with the shorter red arrow pointing to it. Hovering over the Dynamic snapshot will show its VNET.

    A green circle with black text

Description automatically generated

    We can see that we have an additional cluster with an elastic server in the new region.

    A screenshot of a computer

Description automatically generated

  7. Updates, e.g. installing new software, making configuration changes, etc, are to be performed on the persistent server, and once finished, click the Resnapshot button when there are no active sessions on the persistent server. Be sure to wait until the old Dynamic snapshot is replaced with a new one before continuing with the next paragraph.
    It is recommended to check the elastic cluster’s Baseline snapshot to ensure it is pointing to the most recent Dynamic snapshot available. It should happen automatically, and you can also do it manually.

    A screenshot of a computer

Description automatically generated

    When a failover elastic cluster has been prepared, the elastic servers in the failover cluster need to be deleted manually by going to the elastic cluster page and adding /empty to the URL.



    After this is done, you can replace /empty with /maint to expedite the process of replacing the previous Dynamic snapshot for the failover region with the new one. Once the Dynamic snapshot from the original region has been prepared in the new region, elastic servers in the failover region will create. This process on the failover cluster needs to be followed for Auto-resnapshots, too. By default, Auto-resnapshots are done once a week after the persistent server checks for Windows updates at midnight Saturday night/Sunday morning.

  8. For best results, we suggest starting failover servers for 15min once a week to ensure they are available if you ever need them.


Recovery


If it becomes necessary to actually use the failover servers for published apps, go to each app’s page and change the Server cluster from the original cluster to the failover cluster and click Set.

A screenshot of a computer

Description automatically generated

Reverse this process once the original cluster is back online and has been tested.