Wireless Access

 View Only
Expand all | Collapse all

Upgrading MCR and clusters of Controllers

This thread has been viewed 34 times
  • 1.  Upgrading MCR and clusters of Controllers

    Posted 26 days ago

    Hello Everyone, 

    As we know Live Upgrading a cluster of controllers using mobility conductor permits a ZERO Downtime, this topic is just to confirm if upgrading the mobility conductor itself implies a maintenance window or not. There is not any particular configuration on it. Just the 2 clusters of 2 controllers, controlling some APs, airmatch activated. What is the potential impact of doing it during an opened day. Is there any lost of traffic for users ?

    Don't Worry the version compatibility matrix between MCR and Controllers has been verified.



  • 2.  RE: Upgrading MCR and clusters of Controllers

    Posted 26 days ago

    There are some traffic flows that are dependent on MCR reachability, basically anything using OpenFlow like UCC or AirGroup.  As long as you've deployed an L2 pair of MCR there shouldn't be any long term impacts since you'll automatically failover between the two.



    ------------------------------
    Carson Hulcher, ACEX#110
    ------------------------------



  • 3.  RE: Upgrading MCR and clusters of Controllers

    Posted 26 days ago

    Hello chulcher,

    Thank for your reply.

    Just considering MCR upgrade. If i understand, that kind of traffic dependent on MCR reachability will not impact users, so the upgrade can be done out of maintenance window.

    Right ? As we are talking about performance's functionality concerning the traffic dependent on MCR reachability.

    Regards




  • 4.  RE: Upgrading MCR and clusters of Controllers

    Posted 26 days ago

    I'm not understanding what you are trying to get at.

    1. There are some client traffic flows that can depend on the MCR for proper handling, depending on your setup.
    2. If the MC cannot reach the MCR, i.e., MCR is unavailable because of upgrade and reboot, then that could impact client traffic flows.
    3. Properly deploying the MCR in an L2 pair should resolve any reachability issues.

    If you are worried about any possible impact to client traffic, perform the upgrade during a maintenance period.  If you don't care, upgrade whenever.



    ------------------------------
    Carson Hulcher, ACEX#110
    ------------------------------



  • 5.  RE: Upgrading MCR and clusters of Controllers

    Posted 26 days ago

    Upgrade Mobility Conductor will not be seen by users as MM do not carry any traffic from APs. It is quite safe to upgrade MM and standby MM if you have it. You don't need maintenance window for do it. 

    Best, Gorazd



    ------------------------------
    Gorazd Kikelj
    MVP Guru 2024
    ------------------------------



  • 6.  RE: Upgrading MCR and clusters of Controllers

    Posted 26 days ago

    While the MCR isn't in the direct data-plane for client traffic, nor in the direct control-plane for the APs, the MCR does provide some features and functionality that can impact client traffic if the MCR is unavailable.



    ------------------------------
    Carson Hulcher, ACEX#110
    ------------------------------



  • 7.  RE: Upgrading MCR and clusters of Controllers

    Posted 25 days ago

    Agree. There are some functions of MM that can affect end clients. Specifically if you have big setup and many users connected. For smaller setups this usually is not an issue. 

    Best, Gorazd



    ------------------------------
    Gorazd Kikelj
    MVP Guru 2024
    ------------------------------



  • 8.  RE: Upgrading MCR and clusters of Controllers

    Posted 23 days ago

    Sorry to take this post as a boat for my own question. 
    Can you provide more info about this client traffic? Do you know the deep insight about what this traffic is?

    I have 2 MCR (one secondary/backup) and I usually reboot the main MCR from time to time because after some time it starting to act erratic, disappearing down-APs and things like that. And so far, I have not seen any client affected, the secondary MCR takes the VIP pretty soon, etc, etc. 

    However, 2 months ago, my primary MCR crashed by itself with a kernel error and the VIP was responding with the secondary/backup MCR until the Primary recovered by itself after 30 minutes or so and VIP rollback to use the Primary MCR.

    This day in particular, we received a bunch of calls from users around the same time. And I was like scratching my head and telling myself: "they should be good, whatever happened to the MCR should not affect their traffic, MCR is just the super manager of the MMs, MMs are ok and should keep flowing traffic."

    I guess I was wrong, now that I see your post. 




  • 9.  RE: Upgrading MCR and clusters of Controllers

    Posted 23 days ago

    The MCR is usually involved with any traffic flow that requires processing of the OpenFlow stream, namely UCC and AirGroup.  The most visible failure is going to be UCC traffic not getting classified properly and thus handled like normal traffic rather than given priority.



    ------------------------------
    Carson Hulcher, ACEX#110
    ------------------------------



  • 10.  RE: Upgrading MCR and clusters of Controllers

    Posted 23 days ago

    Just to clarify what is what.

    MM (Mobility Conductor/Mobility Master) is controller where configuration is held and it provide some functionality to the cluster like RF optimization,... It does not control APs nor it receive any user traffic from APs.

    MD (Manage Device/Mobility Controller) control APs and user traffic. It receive configuration and is managed by MM.

    MM failover is Active/Standby with VRRP. There is no cluster here.

    MDs can form a cluster up to 12(4) nodes depend on model. Cluster is active/active. Every AP is connected to the cluster with connection to two nodes in the cluster (Active (AAC) / Standby (S-AAC))). If one controller fails traffic is automatically transferred to second controller. Load balancing is in place.

    More info HERE.



    ------------------------------
    Gorazd Kikelj
    MVP Guru 2024
    ------------------------------



  • 11.  RE: Upgrading MCR and clusters of Controllers

    Posted 23 days ago

    Thanks @GorazdKikelj
    That exactly is what I thought it was. Until I read this post and find out the MM (aka MCR) can affect user traffic somehow. I really want to see a data flow diagram to understand it correctly, because apparently UCC can affect the user performance even when the MDs are running without flaws. 




  • 12.  RE: Upgrading MCR and clusters of Controllers

    Posted 23 days ago

    Yeah. There are some functions of MCR that we need to be aware of when upgrading it. I usually didn't encounter any ill effects. But I usually do upgrades in low volume/low client time. 

    Best, Gorazd



    ------------------------------
    Gorazd Kikelj
    MVP Guru 2024
    ------------------------------



  • 13.  RE: Upgrading MCR and clusters of Controllers

    Posted 23 days ago

    So user traffic will never go to MCR (MM). But traffic qualification will and this is where you can have a problem. If traffic is not categorized correctly, it won't get correct QoS settings and can suffer. If network is busy, this can be very noticeable by clients.

    Best, Gorazd



    ------------------------------
    Gorazd Kikelj
    MVP Guru 2024
    ------------------------------



  • 14.  RE: Upgrading MCR and clusters of Controllers

    Posted 25 days ago

    We do the MCR during the working day every time we update. 10 controllers. 3 x L2-connected controller clusters. 1 x L2-connected MM cluster. Around 22k clients during the day.
    Just crack on with the MCR, you won't have a problem. We still do the controller cluster updates when it's quieter over night and stagger the clusters timings.



    ------------------------------
    Nathan
    ------------------------------