Hi,
I'm currently planning to migrate my FAS2240's ggiabit links to 10Gb links.
Since the 10Gb cards are already in place in the filers, the physical part is already done.
I'm currently using the 4 Gb links (e0a -> e0d) as a LACP connection to a stack of juniper devices.
Providing the config is OK on the switch, what woule be the best way to migrate with the minimum downtime ?
I'm planning the following (on each node of the box): - make sure config on the 10Gb ports of the switch is good - plug fibers on both sides - login via console port - cf disable - ifgrp destroy LAG_CIFS - ifgrp create lacp LAG_CIFS -b ip e1a e1b - cf enable
Would it do the job ?
Would I need to restart services like iSCSI/NFS/CIFS/.... ?
Thanks
-----Original Message----- From: toasters-bounces@teaparty.net [mailto:toasters- bounces@teaparty.net] On Behalf Of Laurent CARON Sent: Monday, May 19, 2014 1:49 PM To: Toasters Subject: Migrating from copper gigabit to fiber 10Gb
Hi,
I'm currently planning to migrate my FAS2240's ggiabit links to 10Gb links.
Since the 10Gb cards are already in place in the filers, the physical part is already done.
I'm currently using the 4 Gb links (e0a -> e0d) as a LACP connection to a stack of juniper devices.
Providing the config is OK on the switch, what woule be the best way to migrate with the minimum downtime ?
I'm planning the following (on each node of the box):
- make sure config on the 10Gb ports of the switch is good
- plug fibers on both sides
- login via console port
- cf disable
- ifgrp destroy LAG_CIFS
It is better to completely unconfigure ifgrp before destroying it, just to be on safe side.
- ifgrp create lacp LAG_CIFS -b ip e1a e1b
No ifconfig after that? You will need to configure new interface.
- cf enable
Would it do the job ?
You will also need to edit /etc/rc to make change persistent. And ideally perform takeover/giveback (in both directions) to verify changes in /etc/rc.
Would I need to restart services like iSCSI/NFS/CIFS/.... ?
Should not, at least as long as IP remains the same.
It is also possible to do it as non-disruptively as theoretically possible (but you say "CIFS", so it is already disruptive ...) by performing takeover, editing /etc/rc of taken over partner and performing giveback. Then repeating for second node.
On 19/05/2014 13:28, Borzenkov, Andrey wrote:
It is better to completely unconfigure ifgrp before destroying it, just to be on safe side.
You mean: - ifconfig LAG_CIFS down - ifgrp delete LAG_CIFS e0a - ifgrp delete LAG_CIFS e0b - ifgrp delete LAG_CIFS e0c - ifgrp delete LAG_CIFS e0d - ifgrp destroy LAG_CIFS
- ifgrp create lacp LAG_CIFS -b ip e1a e1b
No ifconfig after that? You will need to configure new interface.
Forgot it. It would mean: ifconfig LAG_CIFS `hostname`-LAG_CIFS netmask 255.255.255.0 partner LAG_iSCSI nfo
You will also need to edit /etc/rc to make change persistent. And ideally perform takeover/giveback (in both directions) to verify changes in /etc/rc.
Sure, that was my plan too. Forgot to mention it.
Would I need to restart services like iSCSI/NFS/CIFS/.... ?
Should not, at least as long as IP remains the same.
It is also possible to do it as non-disruptively as theoretically possible (but you say "CIFS", so it is already disruptive ...) by performing takeover, editing /etc/rc of taken over partner and performing giveback. Then repeating for second node.
True. CIFS is always disruptive, though minimally if failover times are short.
-
Borzenkov, Andrey -
Laurent CARON