Thinking through this logically (in my mind anyway)

place new heads on old 8000-based cluster. If acquired, new storage as well. setup cluster peering and then vserver peering and establish mirrors. Mirror old storage to peer Schedule time and cut over.

In 8.3, there may be a better way. You could setup SVM replication and do a permanent failover of the SVM.

Bottom line, I believe it is possible.

Is there a well documented procedure? I would guess (at least) not (yet).

--tmac

*Tim McCarthy* *Principal Consultant*

On Tue, Jul 21, 2015 at 6:41 AM, Borzenkov, Andrei < andrei.borzenkov@ts.fujitsu.com> wrote:

No procedure is known today. The only possibility is to evacuate data and reinitialize node(s) in new cluster. As long as you have enough space in cluster2 you could do SVM migration to preserve configuration.

*From:* toasters-bounces@teaparty.net [mailto: toasters-bounces@teaparty.net] *On Behalf Of *Milazzo Giacomo *Sent:* Tuesday, July 21, 2015 1:30 PM *To:* Toasters *Subject:* Cluster evolution

Hi everybody,

suppose that for technical (i.e. a 3240HA controller pair that does not fit with a 8060HA one in the same cluster) reason I’ve to start with two different 2 nodes cluster, each of the two managing its respective aggregates and node.

So I can have now:

CLUSTER1-01 and CLUSTER1-02 (3240HA) and CLUSTER2-01 and CLUSTER2-02 (8060HA)

In the future customer could have budget to do a tech refresh on the first cluster changing the heads to an 8000 pairs.

Well, what’s about the merge of the CLUSTER1 nodes to the CLUSTER2 *preserving all data *in CLUSTER1 aggregates? So I mean that I would have in the end a 4 nodes cluster and not two separate 2 nodes ones.

Is there some procedure?

Regards.

---

Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters

That’s right but, as you know, I was thinking to a relocation without allocating new space ($$$) that will be unused at the end of migration, One of the warhorse of 7 Mode, the feature of head swapping and reattaching the old shelves, has been lost. About SVM DR there’s a preceding discussione here opened by me and there are work in progress to avoid some of its limitations. Anyway as Andrei wrote, it’s easy to set up and to manage.

Regards

Da: Borzenkov, Andrei [mailto:andrei.borzenkov@ts.fujitsu.com] Inviato: martedì 21 luglio 2015 13:43 A: tmac tmacmd@gmail.com Cc: Milazzo Giacomo G.Milazzo@sinergy.it; Toasters toasters@teaparty.net Oggetto: RE: Cluster evolution

Yes, if you have enough storage to replicate SVMs you can do it. Unfortunately, SVM DR still has limitations (e.g. no SAN configuration gets replicated) so it may mean manual adjustments.

SVM DR setup is easy and there is Express Guide for it.

From: tmac [mailto:tmacmd@gmail.com] Sent: Tuesday, July 21, 2015 2:37 PM To: Borzenkov, Andrei Cc: Milazzo Giacomo; Toasters Subject: Re: Cluster evolution

Thinking through this logically (in my mind anyway)

place new heads on old 8000-based cluster. If acquired, new storage as well. setup cluster peering and then vserver peering and establish mirrors. Mirror old storage to peer Schedule time and cut over.

In 8.3, there may be a better way. You could setup SVM replication and do a permanent failover of the SVM.

Bottom line, I believe it is possible.

Is there a well documented procedure? I would guess (at least) not (yet).

--tmac

Tim McCarthy Principal Consultant

On Tue, Jul 21, 2015 at 6:41 AM, Borzenkov, Andrei <andrei.borzenkov@ts.fujitsu.commailto:andrei.borzenkov@ts.fujitsu.com> wrote: No procedure is known today. The only possibility is to evacuate data and reinitialize node(s) in new cluster. As long as you have enough space in cluster2 you could do SVM migration to preserve configuration.

From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net] On Behalf Of Milazzo Giacomo Sent: Tuesday, July 21, 2015 1:30 PM To: Toasters Subject: Cluster evolution

Hi everybody,

suppose that for technical (i.e. a 3240HA controller pair that does not fit with a 8060HA one in the same cluster) reason I’ve to start with two different 2 nodes cluster, each of the two managing its respective aggregates and node.

So I can have now:

CLUSTER1-01 and CLUSTER1-02 (3240HA) and CLUSTER2-01 and CLUSTER2-02 (8060HA)

In the future customer could have budget to do a tech refresh on the first cluster changing the heads to an 8000 pairs. Well, what’s about the merge of the CLUSTER1 nodes to the CLUSTER2 preserving all data in CLUSTER1 aggregates? So I mean that I would have in the end a 4 nodes cluster and not two separate 2 nodes ones.

Is there some procedure?

Regards.

_______________________________________________ Toasters mailing list Toasters@teaparty.netmailto:Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters

Things will get better for these types of scenarios, FYI. But right now, yes, you have to jump through some hoops.

From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Borzenkov, Andrei Sent: Tuesday, July 21, 2015 8:41 AM To: NGC-g.milazzo-sinergy.it; tmac Cc: Toasters Subject: RE: Cluster evolution

With two nodes storage is probably split in half, so it may be possible to move part of volumes (SVMs) to partner and part to another cluster to free up storage on one node then relocate node with disks then move second half.

From: Milazzo Giacomo [mailto:G.Milazzo@sinergy.it] Sent: Tuesday, July 21, 2015 3:36 PM To: Borzenkov, Andrei; tmac Cc: Toasters Subject: R: Cluster evolution

That’s right but, as you know, I was thinking to a relocation without allocating new space ($$$) that will be unused at the end of migration, One of the warhorse of 7 Mode, the feature of head swapping and reattaching the old shelves, has been lost. About SVM DR there’s a preceding discussione here opened by me and there are work in progress to avoid some of its limitations. Anyway as Andrei wrote, it’s easy to set up and to manage.

Regards

Da: Borzenkov, Andrei [mailto:andrei.borzenkov@ts.fujitsu.com] Inviato: martedì 21 luglio 2015 13:43 A: tmac <tmacmd@gmail.commailto:tmacmd@gmail.com> Cc: Milazzo Giacomo <G.Milazzo@sinergy.itmailto:G.Milazzo@sinergy.it>; Toasters <toasters@teaparty.netmailto:toasters@teaparty.net> Oggetto: RE: Cluster evolution

Yes, if you have enough storage to replicate SVMs you can do it. Unfortunately, SVM DR still has limitations (e.g. no SAN configuration gets replicated) so it may mean manual adjustments.

SVM DR setup is easy and there is Express Guide for it.

From: tmac [mailto:tmacmd@gmail.com] Sent: Tuesday, July 21, 2015 2:37 PM To: Borzenkov, Andrei Cc: Milazzo Giacomo; Toasters Subject: Re: Cluster evolution

Thinking through this logically (in my mind anyway)

place new heads on old 8000-based cluster. If acquired, new storage as well. setup cluster peering and then vserver peering and establish mirrors. Mirror old storage to peer Schedule time and cut over.

In 8.3, there may be a better way. You could setup SVM replication and do a permanent failover of the SVM.

Bottom line, I believe it is possible.

Is there a well documented procedure? I would guess (at least) not (yet).

--tmac

Tim McCarthy Principal Consultant

On Tue, Jul 21, 2015 at 6:41 AM, Borzenkov, Andrei <andrei.borzenkov@ts.fujitsu.commailto:andrei.borzenkov@ts.fujitsu.com> wrote: No procedure is known today. The only possibility is to evacuate data and reinitialize node(s) in new cluster. As long as you have enough space in cluster2 you could do SVM migration to preserve configuration.

From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net] On Behalf Of Milazzo Giacomo Sent: Tuesday, July 21, 2015 1:30 PM To: Toasters Subject: Cluster evolution

Hi everybody,

suppose that for technical (i.e. a 3240HA controller pair that does not fit with a 8060HA one in the same cluster) reason I’ve to start with two different 2 nodes cluster, each of the two managing its respective aggregates and node.

So I can have now:

CLUSTER1-01 and CLUSTER1-02 (3240HA) and CLUSTER2-01 and CLUSTER2-02 (8060HA)

In the future customer could have budget to do a tech refresh on the first cluster changing the heads to an 8000 pairs. Well, what’s about the merge of the CLUSTER1 nodes to the CLUSTER2 preserving all data in CLUSTER1 aggregates? So I mean that I would have in the end a 4 nodes cluster and not two separate 2 nodes ones.

Is there some procedure?

Regards.

_______________________________________________ Toasters mailing list Toasters@teaparty.netmailto:Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters

Top of my head An option is to reassign disk ownership of the aggregates, to the new controllers that would be part of the same cluster you want to join. Only caution would be not to upgrade the existing environment beyond a supported version for the FAS3240 You can do a lot of prep work beforehand to have minimal disruption, this saves on $$$$ and migration, but downtime is more as it is per aggregate, whereas SMR its scheduled, so you need to do the maths ☺.

Happy Days,

From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Milazzo Giacomo Sent: Tuesday, July 21, 2015 3:36 PM To: Borzenkov, Andrei; tmac Cc: Toasters Subject: R: Cluster evolution

That’s right but, as you know, I was thinking to a relocation without allocating new space ($$$) that will be unused at the end of migration, One of the warhorse of 7 Mode, the feature of head swapping and reattaching the old shelves, has been lost. About SVM DR there’s a preceding discussione here opened by me and there are work in progress to avoid some of its limitations. Anyway as Andrei wrote, it’s easy to set up and to manage.

Regards

Da: Borzenkov, Andrei [mailto:andrei.borzenkov@ts.fujitsu.com] Inviato: martedì 21 luglio 2015 13:43 A: tmac <tmacmd@gmail.commailto:tmacmd@gmail.com> Cc: Milazzo Giacomo <G.Milazzo@sinergy.itmailto:G.Milazzo@sinergy.it>; Toasters <toasters@teaparty.netmailto:toasters@teaparty.net> Oggetto: RE: Cluster evolution

Yes, if you have enough storage to replicate SVMs you can do it. Unfortunately, SVM DR still has limitations (e.g. no SAN configuration gets replicated) so it may mean manual adjustments.

SVM DR setup is easy and there is Express Guide for it.

From: tmac [mailto:tmacmd@gmail.com] Sent: Tuesday, July 21, 2015 2:37 PM To: Borzenkov, Andrei Cc: Milazzo Giacomo; Toasters Subject: Re: Cluster evolution

Thinking through this logically (in my mind anyway)

place new heads on old 8000-based cluster. If acquired, new storage as well. setup cluster peering and then vserver peering and establish mirrors. Mirror old storage to peer Schedule time and cut over.

In 8.3, there may be a better way. You could setup SVM replication and do a permanent failover of the SVM.

Bottom line, I believe it is possible.

Is there a well documented procedure? I would guess (at least) not (yet).

--tmac

Tim McCarthy Principal Consultant

On Tue, Jul 21, 2015 at 6:41 AM, Borzenkov, Andrei <andrei.borzenkov@ts.fujitsu.commailto:andrei.borzenkov@ts.fujitsu.com> wrote: No procedure is known today. The only possibility is to evacuate data and reinitialize node(s) in new cluster. As long as you have enough space in cluster2 you could do SVM migration to preserve configuration.

From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net] On Behalf Of Milazzo Giacomo Sent: Tuesday, July 21, 2015 1:30 PM To: Toasters Subject: Cluster evolution

Hi everybody,

suppose that for technical (i.e. a 3240HA controller pair that does not fit with a 8060HA one in the same cluster) reason I’ve to start with two different 2 nodes cluster, each of the two managing its respective aggregates and node.

So I can have now:

CLUSTER1-01 and CLUSTER1-02 (3240HA) and CLUSTER2-01 and CLUSTER2-02 (8060HA)

In the future customer could have budget to do a tech refresh on the first cluster changing the heads to an 8000 pairs. Well, what’s about the merge of the CLUSTER1 nodes to the CLUSTER2 preserving all data in CLUSTER1 aggregates? So I mean that I would have in the end a 4 nodes cluster and not two separate 2 nodes ones.

Is there some procedure?

Regards.

_______________________________________________ Toasters mailing list Toasters@teaparty.netmailto:Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters

https://library.netapp.com/ecmdocs/ECMP1196986/html/GUID-85C8CF29-1FF6-4DC1-...

Talking only the data aggregates not the SVM

From: Borzenkov, Andrei [mailto:andrei.borzenkov@ts.fujitsu.com] Sent: Wednesday, July 22, 2015 9:21 AM To: Mike Michalakis; Milazzo Giacomo; tmac Cc: Toasters Subject: RE: Cluster evolution

I am a bit confused about your suggestion. How reassigning disk ownership helps to migrate SVM between clusters? Could you elaborate?

From: Mike Michalakis [mailto:mike@directit.com.cy] Sent: Tuesday, July 21, 2015 10:55 PM To: Milazzo Giacomo; Borzenkov, Andrei; tmac Cc: Toasters Subject: RE: Cluster evolution

Top of my head An option is to reassign disk ownership of the aggregates, to the new controllers that would be part of the same cluster you want to join. Only caution would be not to upgrade the existing environment beyond a supported version for the FAS3240 You can do a lot of prep work beforehand to have minimal disruption, this saves on $$$$ and migration, but downtime is more as it is per aggregate, whereas SMR its scheduled, so you need to do the maths ☺.

Happy Days,

From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Milazzo Giacomo Sent: Tuesday, July 21, 2015 3:36 PM To: Borzenkov, Andrei; tmac Cc: Toasters Subject: R: Cluster evolution

That’s right but, as you know, I was thinking to a relocation without allocating new space ($$$) that will be unused at the end of migration, One of the warhorse of 7 Mode, the feature of head swapping and reattaching the old shelves, has been lost. About SVM DR there’s a preceding discussione here opened by me and there are work in progress to avoid some of its limitations. Anyway as Andrei wrote, it’s easy to set up and to manage.

Regards

Da: Borzenkov, Andrei [mailto:andrei.borzenkov@ts.fujitsu.com] Inviato: martedì 21 luglio 2015 13:43 A: tmac <tmacmd@gmail.commailto:tmacmd@gmail.com> Cc: Milazzo Giacomo <G.Milazzo@sinergy.itmailto:G.Milazzo@sinergy.it>; Toasters <toasters@teaparty.netmailto:toasters@teaparty.net> Oggetto: RE: Cluster evolution

Yes, if you have enough storage to replicate SVMs you can do it. Unfortunately, SVM DR still has limitations (e.g. no SAN configuration gets replicated) so it may mean manual adjustments.

SVM DR setup is easy and there is Express Guide for it.

From: tmac [mailto:tmacmd@gmail.com] Sent: Tuesday, July 21, 2015 2:37 PM To: Borzenkov, Andrei Cc: Milazzo Giacomo; Toasters Subject: Re: Cluster evolution

Thinking through this logically (in my mind anyway)

place new heads on old 8000-based cluster. If acquired, new storage as well. setup cluster peering and then vserver peering and establish mirrors. Mirror old storage to peer Schedule time and cut over.

In 8.3, there may be a better way. You could setup SVM replication and do a permanent failover of the SVM.

Bottom line, I believe it is possible.

Is there a well documented procedure? I would guess (at least) not (yet).

--tmac

Tim McCarthy Principal Consultant

On Tue, Jul 21, 2015 at 6:41 AM, Borzenkov, Andrei <andrei.borzenkov@ts.fujitsu.commailto:andrei.borzenkov@ts.fujitsu.com> wrote: No procedure is known today. The only possibility is to evacuate data and reinitialize node(s) in new cluster. As long as you have enough space in cluster2 you could do SVM migration to preserve configuration.

From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net] On Behalf Of Milazzo Giacomo Sent: Tuesday, July 21, 2015 1:30 PM To: Toasters Subject: Cluster evolution

Hi everybody,

suppose that for technical (i.e. a 3240HA controller pair that does not fit with a 8060HA one in the same cluster) reason I’ve to start with two different 2 nodes cluster, each of the two managing its respective aggregates and node.

So I can have now:

CLUSTER1-01 and CLUSTER1-02 (3240HA) and CLUSTER2-01 and CLUSTER2-02 (8060HA)

In the future customer could have budget to do a tech refresh on the first cluster changing the heads to an 8000 pairs. Well, what’s about the merge of the CLUSTER1 nodes to the CLUSTER2 preserving all data in CLUSTER1 aggregates? So I mean that I would have in the end a 4 nodes cluster and not two separate 2 nodes ones.

Is there some procedure?

Regards.

_______________________________________________ Toasters mailing list Toasters@teaparty.netmailto:Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters

According to NetApp this is supported, provide same versions on DOT

From: Borzenkov, Andrei [mailto:andrei.borzenkov@ts.fujitsu.com] Sent: Wednesday, July 22, 2015 1:58 PM To: Mike Michalakis; Milazzo Giacomo; tmac Cc: Toasters Subject: RE: Cluster evolution

This is 7-Mode documentation. It does not apply to C-Mode.

From: Mike Michalakis [mailto:mike@directit.com.cy] Sent: Wednesday, July 22, 2015 1:49 PM To: Borzenkov, Andrei; Milazzo Giacomo; tmac Cc: Toasters Subject: RE: Cluster evolution

https://library.netapp.com/ecmdocs/ECMP1196986/html/GUID-85C8CF29-1FF6-4DC1-...

Talking only the data aggregates not the SVM

From: Borzenkov, Andrei [mailto:andrei.borzenkov@ts.fujitsu.com] Sent: Wednesday, July 22, 2015 9:21 AM To: Mike Michalakis; Milazzo Giacomo; tmac Cc: Toasters Subject: RE: Cluster evolution

I am a bit confused about your suggestion. How reassigning disk ownership helps to migrate SVM between clusters? Could you elaborate?

From: Mike Michalakis [mailto:mike@directit.com.cy] Sent: Tuesday, July 21, 2015 10:55 PM To: Milazzo Giacomo; Borzenkov, Andrei; tmac Cc: Toasters Subject: RE: Cluster evolution

Top of my head An option is to reassign disk ownership of the aggregates, to the new controllers that would be part of the same cluster you want to join. Only caution would be not to upgrade the existing environment beyond a supported version for the FAS3240 You can do a lot of prep work beforehand to have minimal disruption, this saves on $$$$ and migration, but downtime is more as it is per aggregate, whereas SMR its scheduled, so you need to do the maths ☺.

Happy Days,

From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Milazzo Giacomo Sent: Tuesday, July 21, 2015 3:36 PM To: Borzenkov, Andrei; tmac Cc: Toasters Subject: R: Cluster evolution

That’s right but, as you know, I was thinking to a relocation without allocating new space ($$$) that will be unused at the end of migration, One of the warhorse of 7 Mode, the feature of head swapping and reattaching the old shelves, has been lost. About SVM DR there’s a preceding discussione here opened by me and there are work in progress to avoid some of its limitations. Anyway as Andrei wrote, it’s easy to set up and to manage.

Regards

Da: Borzenkov, Andrei [mailto:andrei.borzenkov@ts.fujitsu.com] Inviato: martedì 21 luglio 2015 13:43 A: tmac <tmacmd@gmail.commailto:tmacmd@gmail.com> Cc: Milazzo Giacomo <G.Milazzo@sinergy.itmailto:G.Milazzo@sinergy.it>; Toasters <toasters@teaparty.netmailto:toasters@teaparty.net> Oggetto: RE: Cluster evolution

Yes, if you have enough storage to replicate SVMs you can do it. Unfortunately, SVM DR still has limitations (e.g. no SAN configuration gets replicated) so it may mean manual adjustments.

SVM DR setup is easy and there is Express Guide for it.

From: tmac [mailto:tmacmd@gmail.com] Sent: Tuesday, July 21, 2015 2:37 PM To: Borzenkov, Andrei Cc: Milazzo Giacomo; Toasters Subject: Re: Cluster evolution

Thinking through this logically (in my mind anyway)

place new heads on old 8000-based cluster. If acquired, new storage as well. setup cluster peering and then vserver peering and establish mirrors. Mirror old storage to peer Schedule time and cut over.

In 8.3, there may be a better way. You could setup SVM replication and do a permanent failover of the SVM.

Bottom line, I believe it is possible.

Is there a well documented procedure? I would guess (at least) not (yet).

--tmac

Tim McCarthy Principal Consultant

On Tue, Jul 21, 2015 at 6:41 AM, Borzenkov, Andrei <andrei.borzenkov@ts.fujitsu.commailto:andrei.borzenkov@ts.fujitsu.com> wrote: No procedure is known today. The only possibility is to evacuate data and reinitialize node(s) in new cluster. As long as you have enough space in cluster2 you could do SVM migration to preserve configuration.

From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net] On Behalf Of Milazzo Giacomo Sent: Tuesday, July 21, 2015 1:30 PM To: Toasters Subject: Cluster evolution

Hi everybody,

suppose that for technical (i.e. a 3240HA controller pair that does not fit with a 8060HA one in the same cluster) reason I’ve to start with two different 2 nodes cluster, each of the two managing its respective aggregates and node.

So I can have now:

CLUSTER1-01 and CLUSTER1-02 (3240HA) and CLUSTER2-01 and CLUSTER2-02 (8060HA)

In the future customer could have budget to do a tech refresh on the first cluster changing the heads to an 8000 pairs. Well, what’s about the merge of the CLUSTER1 nodes to the CLUSTER2 preserving all data in CLUSTER1 aggregates? So I mean that I would have in the end a 4 nodes cluster and not two separate 2 nodes ones.

Is there some procedure?

Regards.

_______________________________________________ Toasters mailing list Toasters@teaparty.netmailto:Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters

Thanks Justin,

I think that there has been a little bit of confusion among my first opening questions and the last intervention.

Regards

- Sent by mobile -

-------- Messaggio originale -------- Da: "Parisi, Justin" Justin.Parisi@netapp.com Data: 22/07/2015 16:04 (GMT+01:00) A: Mike Michalakis mike@directit.com.cy, "Borzenkov, Andrei" andrei.borzenkov@ts.fujitsu.com, Milazzo Giacomo G.Milazzo@sinergy.it, tmac tmacmd@gmail.com Cc: Toasters toasters@teaparty.net Oggetto: RE: Cluster evolution

No, you cannot migrate SVMs between clusters just by doing disk re-assignment in cDOT.

The reason being is that each volume has a specific SVM and cluster UUID assigned to it. If you migrate shelves, the SVM will still think it’s in the other cluster.

From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Mike Michalakis Sent: Wednesday, July 22, 2015 7:44 AM To: Borzenkov, Andrei; NGC-g.milazzo-sinergy.it; tmac Cc: Toasters Subject: RE: Cluster evolution

According to NetApp this is supported, provide same versions on DOT

From: Borzenkov, Andrei [mailto:andrei.borzenkov@ts.fujitsu.com] Sent: Wednesday, July 22, 2015 1:58 PM To: Mike Michalakis; Milazzo Giacomo; tmac Cc: Toasters Subject: RE: Cluster evolution

This is 7-Mode documentation. It does not apply to C-Mode.

From: Mike Michalakis [mailto:mike@directit.com.cy] Sent: Wednesday, July 22, 2015 1:49 PM To: Borzenkov, Andrei; Milazzo Giacomo; tmac Cc: Toasters Subject: RE: Cluster evolution

https://library.netapp.com/ecmdocs/ECMP1196986/html/GUID-85C8CF29-1FF6-4DC1-...

Talking only the data aggregates not the SVM

From: Borzenkov, Andrei [mailto:andrei.borzenkov@ts.fujitsu.com] Sent: Wednesday, July 22, 2015 9:21 AM To: Mike Michalakis; Milazzo Giacomo; tmac Cc: Toasters Subject: RE: Cluster evolution

I am a bit confused about your suggestion. How reassigning disk ownership helps to migrate SVM between clusters? Could you elaborate?

From: Mike Michalakis [mailto:mike@directit.com.cy] Sent: Tuesday, July 21, 2015 10:55 PM To: Milazzo Giacomo; Borzenkov, Andrei; tmac Cc: Toasters Subject: RE: Cluster evolution

Top of my head An option is to reassign disk ownership of the aggregates, to the new controllers that would be part of the same cluster you want to join. Only caution would be not to upgrade the existing environment beyond a supported version for the FAS3240 You can do a lot of prep work beforehand to have minimal disruption, this saves on $$$$ and migration, but downtime is more as it is per aggregate, whereas SMR its scheduled, so you need to do the maths :).

Happy Days,

From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Milazzo Giacomo Sent: Tuesday, July 21, 2015 3:36 PM To: Borzenkov, Andrei; tmac Cc: Toasters Subject: R: Cluster evolution

That’s right but, as you know, I was thinking to a relocation without allocating new space ($$$) that will be unused at the end of migration, One of the warhorse of 7 Mode, the feature of head swapping and reattaching the old shelves, has been lost. About SVM DR there’s a preceding discussione here opened by me and there are work in progress to avoid some of its limitations. Anyway as Andrei wrote, it’s easy to set up and to manage.

Regards

Da: Borzenkov, Andrei [mailto:andrei.borzenkov@ts.fujitsu.com] Inviato: martedì 21 luglio 2015 13:43 A: tmac <tmacmd@gmail.commailto:tmacmd@gmail.com> Cc: Milazzo Giacomo <G.Milazzo@sinergy.itmailto:G.Milazzo@sinergy.it>; Toasters <toasters@teaparty.netmailto:toasters@teaparty.net> Oggetto: RE: Cluster evolution

Yes, if you have enough storage to replicate SVMs you can do it. Unfortunately, SVM DR still has limitations (e.g. no SAN configuration gets replicated) so it may mean manual adjustments.

SVM DR setup is easy and there is Express Guide for it.

From: tmac [mailto:tmacmd@gmail.com] Sent: Tuesday, July 21, 2015 2:37 PM To: Borzenkov, Andrei Cc: Milazzo Giacomo; Toasters Subject: Re: Cluster evolution

Thinking through this logically (in my mind anyway)

place new heads on old 8000-based cluster. If acquired, new storage as well. setup cluster peering and then vserver peering and establish mirrors. Mirror old storage to peer Schedule time and cut over.

In 8.3, there may be a better way. You could setup SVM replication and do a permanent failover of the SVM.

Bottom line, I believe it is possible.

Is there a well documented procedure? I would guess (at least) not (yet).

--tmac

Tim McCarthy Principal Consultant

On Tue, Jul 21, 2015 at 6:41 AM, Borzenkov, Andrei <andrei.borzenkov@ts.fujitsu.commailto:andrei.borzenkov@ts.fujitsu.com> wrote: No procedure is known today. The only possibility is to evacuate data and reinitialize node(s) in new cluster. As long as you have enough space in cluster2 you could do SVM migration to preserve configuration.

From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net] On Behalf Of Milazzo Giacomo Sent: Tuesday, July 21, 2015 1:30 PM To: Toasters Subject: Cluster evolution

Hi everybody,

suppose that for technical (i.e. a 3240HA controller pair that does not fit with a 8060HA one in the same cluster) reason I’ve to start with two different 2 nodes cluster, each of the two managing its respective aggregates and node.

So I can have now:

CLUSTER1-01 and CLUSTER1-02 (3240HA) and CLUSTER2-01 and CLUSTER2-02 (8060HA)

In the future customer could have budget to do a tech refresh on the first cluster changing the heads to an 8000 pairs. Well, what’s about the merge of the CLUSTER1 nodes to the CLUSTER2 preserving all data in CLUSTER1 aggregates? So I mean that I would have in the end a 4 nodes cluster and not two separate 2 nodes ones.

Is there some procedure?

Regards.

_______________________________________________ Toasters mailing list Toasters@teaparty.netmailto:Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters