cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1216
Views
5
Helpful
2
Replies

Multipod ACI Software upgrade

brian.holmes
Beginner
Beginner

Do most deployments perform software upgrades for all PODs on the same weekend or do they split up the upgrades into separate weekend per POD?

Brian Holmes
Verizon
1 Accepted Solution

Accepted Solutions

Robert Burns
Cisco Employee
Cisco Employee

Typically, this decision is driven by the Application deployment. Are applications isolated to Pods or not.  The most common upgrade schemes I've seen are:

1) Odd / Evens Entire Fabric w/ Soaking Period In Between

Maintenance Period 1 : All Pods / Odd Switches

Maintenance Period 2: All Pods / Even Switches

2) Pod by Pod Upgrade w/ Soaking Period In Between

Maintenance Period 1 : Pod1 / All Switches

Maintenance Period 2:  Pod2 / All Switches

Maintenance Period n:  Podn / All Switches

3) Odd / Even & Pod by Pod Upgrade w/ Soaking Period In Between

Maintenance Period 1 : Pod1 / Odds

Maintenance Period 2: Pod 1 / Evens

Maintenance Period 3: Pod 2 / Odds

Maintenance Period 4: Pod 2 / Evens

Maintenance Period n: Podn / Odds

Maintenance Period n+1: Podn / Evens

If Applications are only hosted on certain Pods and not stretched across pods then the first option works well.  You can complete an upgrade with only two maintenance windows and allow for some time in between to validate everything.  As you start to get more granular with your change control, the time its going to take to upgrade grows as you can see.  You have to balance application availability impact w/ time invested for performing the upgrade.   It's fully supported to run ACI fabrics in a mixed-version for a period of time, but I would try to limit this to less than a month if possible - Especially across major versions where new features are introduced. 

 

Others can chime in with their experience.

Robert

 

 

View solution in original post

2 Replies 2

Robert Burns
Cisco Employee
Cisco Employee

Typically, this decision is driven by the Application deployment. Are applications isolated to Pods or not.  The most common upgrade schemes I've seen are:

1) Odd / Evens Entire Fabric w/ Soaking Period In Between

Maintenance Period 1 : All Pods / Odd Switches

Maintenance Period 2: All Pods / Even Switches

2) Pod by Pod Upgrade w/ Soaking Period In Between

Maintenance Period 1 : Pod1 / All Switches

Maintenance Period 2:  Pod2 / All Switches

Maintenance Period n:  Podn / All Switches

3) Odd / Even & Pod by Pod Upgrade w/ Soaking Period In Between

Maintenance Period 1 : Pod1 / Odds

Maintenance Period 2: Pod 1 / Evens

Maintenance Period 3: Pod 2 / Odds

Maintenance Period 4: Pod 2 / Evens

Maintenance Period n: Podn / Odds

Maintenance Period n+1: Podn / Evens

If Applications are only hosted on certain Pods and not stretched across pods then the first option works well.  You can complete an upgrade with only two maintenance windows and allow for some time in between to validate everything.  As you start to get more granular with your change control, the time its going to take to upgrade grows as you can see.  You have to balance application availability impact w/ time invested for performing the upgrade.   It's fully supported to run ACI fabrics in a mixed-version for a period of time, but I would try to limit this to less than a month if possible - Especially across major versions where new features are introduced. 

 

Others can chime in with their experience.

Robert

 

 

We are performing version 2 of Roberts concept but inside each of the the Pods we do it in multiple groups.
Even spines
Odd spines
Even border leaves
Odd border leaves

Even leaves of x86
Odd leaves of x86
Even leaves of Storage
Odd leaves of storage
...
...
Christoph

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers