2SZ in 1Cluster. How should I execute the upgrade procedure: on which of them first?

  • 1
  • Question
  • Updated 3 weeks ago
  • Answered
2SZ in 1Cluster. How should I execute the upgrade procedure: on which of them first?
Photo of Alexey

Alexey

  • 7 Posts
  • 0 Reply Likes

Posted 3 weeks ago

  • 1
Photo of Martin

Martin, Official Rep

  • 274 Posts
  • 67 Reply Likes
Hi Alexey,

Before you upgrade you should check and do some steps.

1. Login into one of the two SZ nodes, it does not matter which of the two.
2. Make a cluster backup
3. Check in the release notes of the version you want to install if the AP models that you currently use are still supported.
4. If they are then continue and on one of two SZ nodes, does not matter which one do the upgrade itself.
5. be patient, upgrade takes time.

Kind regards
Martin

Photo of Alexey

Alexey

  • 7 Posts
  • 0 Reply Likes
Exuse me, d u understand the things u write?  
When I start upgrade FOLLOWer SZ, after it finished up, it become the LEADER, so? And it began load new SW-version upon the APs automatically? My services interrupting durig this. Second SZ became FOLLOWer & waitig for the same procedure?
Photo of Albert Pierson

Albert Pierson, Employee

  • 34 Posts
  • 28 Reply Likes
The  multinode cluster GUI is a "single pane of glass" where the GUI on any node in the cluster has a complete view of most of the data and most operations can be performed from any node. 

Some exceptions are diagnostic scripts which usually need to be uploaded to each node, but in later versions there is an option to do this from a single node as well.

Be aware, while any node can monitor the full cluster, the chosen node will actually be handling the load of that monitoring and configuration.  There is a tendency to choose the first node to do most of the work but good practice, particularly in a Service Provider environment with multiple administrators, is to spread the load and log into different nodes.  This is also true of API and SNMP calls, which are directed against a single node IP/URL.  Often the first IP is chosen out of habit, but it is good to spread this out between the nodes.

Finally, the Leader node is dynamically chosen and it is just selected to synchronize the cluster to a single time.  SCG/SZ is an Active/Active redundancy system where all nodes are peer's, no node is a "primary" or "backup".  It really does not matter which node is acting as leader and it can change.  This node will be the NTP client getting time synchronization from the Internet and acting as NTP server for the other nodes and the Access Points. 

I hope this information is useful.

Thanks for choosing Ruckus Networks products.

Albert
Photo of Alexey

Alexey

  • 7 Posts
  • 0 Reply Likes
Thank u, Albert .
I ve understood some after "SCG/SZ is an Active/Active redundancy system where all nodes are peer's, no node is a "primary" or "backup"."

Photo of Albert Pierson

Albert Pierson, Employee

  • 34 Posts
  • 28 Reply Likes
Hi Alexy

You can start the upgrade by logging into either/any node's GUI, it does not matter if it is the follower or leader.

The system will first update the data and then begin upgrading the firmware on each nodes.  The system should continue controlling the AP's and providing service until all nodes are upgraded and the cluster is restarted.  AP service to clients using PSK or open authentication should not have service interrupted but services provided through the SZ like captive portal and proxied authentication will be interrupted when the cluster reboots.

AP code does not get upgraded until you select to do so per AP zone.  The exception to this is SZ-100 and vSZ-E prior to 3.5 where there was only a single zone architecture.


The upgrade procedure was enhanced in version 3.5 and above so that node firmware is actually upgraded at the same time decreasing the upgrade time and providing a more comprehensive upgrade progress in the GUI

I hope this answers your questions

Albert