Upgrading the FILE side will require a reboot of the datamover. This reboot can take anywhere from a minute to 10 minutes. During that time all FILE services will be down so please plan accordingly. Upgrading the BLOCK SPs is a different matter. The system can trespass the luns to the other SP and maintain data access if you have proper multipathing setup. This allows you to reboot 1 SP at a time, but running this way will put extra load on the other SP, so it's best to do this during a period of little to no activity.
because according to the EMC support through email, they said that there is a brief 7-10 minutes outage for the CIFS share as it is managed by the control station, but not to the LUN as it is served by the SP A and B.
by the way control station does not manage CIFS nor NFS services, those responsibilities are handled by the datamovers (x-blades). You can shutdown the control station and CIFS/NFS services will continue to function.
So there is now way to keep the CIFS share alive during the upgrade ?
in my VNX 5300 and 5500 I can see that there are multiple data mover blades, but how can they not acting the same as SP to support failover one after the other ?
I assume the control station is the management console GUI for the Block (Clariion) and File (Cellera) component.
i am afraid not, CIFS is a stateful protocol and should not be interrupted but when datamovers failover from primary to standby that's exactly what happens. That's why you want to make sure there is nothing going during the upgrade, i tell my CIFS users to save all their work.
AlbertWT wrote:
I assume the control station is the management console GUI for the Block (Clariion) and File (Cellera) component.
correct, it does a lot of other things in the background but management interface is its primary duty.
It is never a bad idea to save work or backup but not fully necessary
Any modern CIFS client will automatically reconnect when the server is available again.
It is more of an issue for NFS clients that can time out – particularly when used as a vmWare data store
The exact downtime depends on the model, config and which release
The customer service figures are quite conservative
We have been continuously improving the reboot/failover times over the DART and VNX OE releases
I’ve seen downtimes there of less than 2 minutes – some even at the 1 minute mark
If you do an in-family upgrade x.x.y to x.x.z then the upgrade will first upgade the standby data mover and then failover, upgrade primary and failback – which is shorter
Specifically for upgrading from 7.0 to 7.1 – if you want minimum downtime use the CLI upgrade
The USM upgrade treats it as an out-of-family upgrade with data mover reboot while the CLI gives you a choice of failover.
sthulin
2 Intern
•
181 Posts
0
December 4th, 2012 18:00
Upgrading the FILE side will require a reboot of the datamover. This reboot can take anywhere from a minute to 10 minutes. During that time all FILE services will be down so please plan accordingly. Upgrading the BLOCK SPs is a different matter. The system can trespass the luns to the other SP and maintain data access if you have proper multipathing setup. This allows you to reboot 1 SP at a time, but running this way will put extra load on the other SP, so it's best to do this during a period of little to no activity.
dynamox
9 Legend
•
20.4K Posts
0
December 4th, 2012 19:00
by the way control station does not manage CIFS nor NFS services, those responsibilities are handled by the datamovers (x-blades). You can shutdown the control station and CIFS/NFS services will continue to function.
Albertwt
2 Intern
•
164 Posts
0
December 4th, 2012 20:00
Hi Dynamox,
So there is now way to keep the CIFS share alive during the upgrade ?
in my VNX 5300 and 5500 I can see that there are multiple data mover blades, but how can they not acting the same as SP to support failover one after the other ?
I assume the control station is the management console GUI for the Block (Clariion) and File (Cellera) component.
Albertwt
2 Intern
•
164 Posts
0
December 4th, 2012 21:00
Ah ok, so just to be safe, I'll instruct my users to save their work and avoid accessing the CIFS share during the maintenance window.
dynamox
9 Legend
•
20.4K Posts
0
December 4th, 2012 21:00
i am afraid not, CIFS is a stateful protocol and should not be interrupted but when datamovers failover from primary to standby that's exactly what happens. That's why you want to make sure there is nothing going during the upgrade, i tell my CIFS users to save all their work.
correct, it does a lot of other things in the background but management interface is its primary duty.
Rainer_EMC
4 Operator
•
8.6K Posts
0
December 5th, 2012 00:00
It is never a bad idea to save work or backup but not fully necessary
Any modern CIFS client will automatically reconnect when the server is available again.
It is more of an issue for NFS clients that can time out – particularly when used as a vmWare data store
The exact downtime depends on the model, config and which release
The customer service figures are quite conservative
We have been continuously improving the reboot/failover times over the DART and VNX OE releases
I’ve seen downtimes there of less than 2 minutes – some even at the 1 minute mark
If you do an in-family upgrade x.x.y to x.x.z then the upgrade will first upgade the standby data mover and then failover, upgrade primary and failback – which is shorter
Specifically for upgrading from 7.0 to 7.1 – if you want minimum downtime use the CLI upgrade
The USM upgrade treats it as an out-of-family upgrade with data mover reboot while the CLI gives you a choice of failover.
Rainer
Albertwt
2 Intern
•
164 Posts
0
December 5th, 2012 15:00
Rainer, thank you for the response,
luckilly I don't have NFS share for the VMware datastore, since the datastore is block level as LUNs.
just a normal CIFS share used by Windows Server.
CLI upgrade ? where can I find that documentation.
yes you are right, with the USM, it is easier than typing the full command line from the CLI ssh console.
Rainer_EMC
4 Operator
•
8.6K Posts
0
December 6th, 2012 00:00
Typically in the VNX procedure generator – please ask your service provider to help you