Skip navigation
All Places > CloudGuard IaaS > Blog

CloudGuard IaaS

2 posts

Hello Everyone,

 

In an effort to improve customer awareness and add visibility to our announcements regarding feature releases, I'll be posting blog entries whenever we have an exciting new feature.

 

Hopefully, this will both be a good source for you to find out about exciting new features, as well as a platform for you to give us some direct feedback about those new releases.

 

I'll start with a few recent announcements (and possibly repost some older ones just in case there are readers who missed them), and going forward I'll be posting about new releases as they are announced.

 

Edit: I'll publish all other posts under my personal Blog CloudGuard IaaS Announcements 

Hi, a customer challenged me to replace an ailing member of a cluster with a brand new one. here are the steps:


(This was tested on an  R77.30 cluster Afand R80.10 management server)

We assume that we have a cluster where in azure, the names of the cluster member VMs are CL1 and CL2. The name of the resource group is CLrg. We want to remove CL2 and replace it with a new member of the cluster. The steps are

 

  1. From Azure, delete all the resources in the CLrg resource group that are part of CL2, (all these resources’ names will begin with CL2. They include the VM, IP address, disks, vNICs)
  2. From the Azure portal record the ID of the availability set of the cluster (you’ll find it under “properties” of the availability set, in the CLrg resource group.)
  3. From Azure, using some new resource group, go through the motions of creating a single gateway (using the single gateway template). For all the parameter values you enter, make sure you adhere to 6.b-6.g below.
  4. After the verification, but before you deploy, you have a chance to download the template. Download it.
  5. Edit the template file you downloaded by adding the “availabilityset” key/value to the “properties” of the “virtual machine” section of the template. It should look like this:
  6. Use your favorite tool (e.g., powershell) to deploy the modified template but note the following
    1. Deploy to the same resource group as the cluster
    2. The VM name must be the exact same name as the VM you deleted (in this vase “CL2”)
    3. The version must be the same as the cluster
    4. The license must be the same as the cluster
    5. The installation type must be “gateway”
    6. The machine type must be the same as the cluster members
    7. The Vnet must be the same existinig vnet and the subnets must be the same subnets as the other cluster member
  7. Verify that the template was successfully deployed by looking, in the Azure portal, at the members of the availability set. The new member should be there
  8. Prepare the gateway to be clustered. SSH into the new gateway and
    1. cpconfig--> (6) Enable cluster membership for this gateway
    2. Reboot
    3. Copy the HA config file from the member that’s still on the cluster. In R77.30 the following command should do it (assuming the access policy allows it!) by scp from the new gateway to the existing gateway
      1. scp admin@<ipaddressofexistingmember>:/opt/CPsuite-R77/fw1/conf/azure-ha.json /opt/CPsuite-R77/fw1/conf
    4. Reconfigure the configuration using the commands
      1. azure-ha-conf --client-id <client id> --client-secret <client secret> --force
      2. $FWDIR/scripts/azure_ha_cli.py reconf
    5. Add the required routes to the new gateway (the same routes you added originally to the cluster members) 
  9. From SmartConsole
    1. Remove the old member from the cluster
    2. Publish
    3. Add the new gateway as a cluster member
    4. From network management, Get interfaces on the cluster
    5. Publish and push policy to cluster
  10. Test failover