Highlighted
Knowledge Partner
Knowledge Partner
2072 views

Rolling Cluster Upgrade (OES2 to OES11) - GPT partition

We've got an OES2 SP3 cluster that we'll be rolling cluster upgrading to OES11 SP2.

We are currently at max capacity for several of the NSS volumes (2 TB).

If I'm reading/interpreting the OES11 SP2 docs correctly:

AFTER the cluster upgrade is complete, the only way I can get to larger volumes will be to create new LUNs on the SAN and intialize those with GPT. Then I could do the NSS Pool Move feature to get the existing 2 TB volumes to the larger setup?

Is that correct?

Or is there a better way that doesnt' require massive downtime?
Labels (1)
0 Likes
5 Replies
Knowledge Partner
Knowledge Partner

Re: Rolling Cluster Upgrade (OES2 to OES11) - GPT partition

Kevin,

Am 23.04.2015 um 19:46 schrieb kjhurni:
>
> We've got an OES2 SP3 cluster that we'll be rolling cluster upgrading to
> OES11 SP2.
>
> We are currently at max capacity for several of the NSS volumes (2 TB).
>
> If I'm reading/interpreting the OES11 SP2 docs correctly:
>
> AFTER the cluster upgrade is complete, the only way I can get to larger
> volumes will be to create new LUNs on the SAN and intialize those with
> GPT. Then I could do the NSS Pool Move feature to get the existing 2 TB
> volumes to the larger setup?
>
> Is that correct?


No, it's certainly not the only way at all, but one of the more sensible
ones. You could of course also just simply add additional luns
/partitions and expand the pools from there.

> Or is there a better way that doesnt' require massive downtime?


Errr, the pool move function requires absolutely zero downtime.

CU,
--
Massimo Rosen
Novell Knowledge Partner
No emails please!
http://www.cfc-it.de
CU,
--
Massimo Rosen
Micro Focus Knowledge Partner
No emails please!
http://www.cfc-it.de
0 Likes
Knowledge Partner
Knowledge Partner

Re: Rolling Cluster Upgrade (OES2 to OES11) - GPT partition

mrosen;2391945 wrote:
Kevin,

Am 23.04.2015 um 19:46 schrieb kjhurni:
>
> We've got an OES2 SP3 cluster that we'll be rolling cluster upgrading to
> OES11 SP2.
>
> We are currently at max capacity for several of the NSS volumes (2 TB).
>
> If I'm reading/interpreting the OES11 SP2 docs correctly:
>
> AFTER the cluster upgrade is complete, the only way I can get to larger
> volumes will be to create new LUNs on the SAN and intialize those with
> GPT. Then I could do the NSS Pool Move feature to get the existing 2 TB
> volumes to the larger setup?
>
> Is that correct?


No, it's certainly not the only way at all, but one of the more sensible
ones. You could of course also just simply add additional luns
/partitions and expand the pools from there.

> Or is there a better way that doesnt' require massive downtime?


Errr, the pool move function requires absolutely zero downtime.

CU,
--
Massimo Rosen
Novell Knowledge Partner
No emails please!
http://www.cfc-it.de


Thanks Massimo. Just wanted a sanity check as I've never done the pool move and stuff before.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Rolling Cluster Upgrade (OES2 to OES11) - GPT partition

In article <kjhurni.6vtbqp@no-mx.forums.microfocus.com>, Kjhurni wrote:
> We are currently at max capacity for several of the NSS volumes (2 TB).

I was on the understanding that you could bind multiple partitions to
create NSS volumes up to 8TB. But I'd be hesitant to do that for a
clustered volume as well.

> I could do the NSS Pool Move feature to get the existing 2 TB
> volumes to the larger setup?
> Or is there a better way that doesnt' require massive downtime?

My first thought is the migration wizard so that the bulk of the copy can
be done while system is live but in the quieter times. Then the final
update with down time should be much faster.

But then do you really need down time for the Pool Move feature?
https://www.novell.com/documentation/oes11/stor_nss_lx/data/bwtebhm.html
Certainly indicates it can be done live on a cluster with the move
process being cluster aware.


Andy of
http://KonecnyConsulting.ca in Toronto
Knowledge Partner
http://forums.novell.com/member.php/75037-konecnya
If you find a post helpful and are logged in the Web interface, please
show your appreciation by clicking on the star below. Thanks!

___
Andy of Konecny Consulting in Toronto
Knowledge Partner Profile
If you find a post helpful, click the Like button below. Thanks!
0 Likes
Knowledge Partner
Knowledge Partner

Re: Rolling Cluster Upgrade (OES2 to OES11) - GPT partition

konecnya;2391972 wrote:
In article <kjhurni.6vtbqp@no-mx.forums.microfocus.com>, Kjhurni wrote:
> We are currently at max capacity for several of the NSS volumes (2 TB).

I was on the understanding that you could bind multiple partitions to
create NSS volumes up to 8TB. But I'd be hesitant to do that for a
clustered volume as well.

> I could do the NSS Pool Move feature to get the existing 2 TB
> volumes to the larger setup?
> Or is there a better way that doesnt' require massive downtime?

My first thought is the migration wizard so that the bulk of the copy can
be done while system is live but in the quieter times. Then the final
update with down time should be much faster.

But then do you really need down time for the Pool Move feature?
https://www.novell.com/documentation/oes11/stor_nss_lx/data/bwtebhm.html
Certainly indicates it can be done live on a cluster with the move
process being cluster aware.


Andy of
http://KonecnyConsulting.ca in Toronto
Knowledge Partner
http://forums.novell.com/member.php/75037-konecnya
If you find a post helpful and are logged in the Web interface, please
show your appreciation by clicking on the star below. Thanks!


Migration = pew pew (re-doing IP's/etc and copying 4 TB of data is ugly especially when it's lots of tiny stuff).
haha

Anyway, when I asked about a better way that doesn't require massive downtime what I meant was:

Is there a better way vs. Pool Move that doesn't require massive downtime (in other words, the "other way" having the massive downtime, not the Pool Move).

Choice A = Pool Move = No downtime
But let's say that's not a good option (for whatever reason) and someone says use Choice B. But Choice B ends up requiring downtime (like the data copy option).

I just didn't know if Pool Move required that you create the partition ahead of time (so you can choose GPT) or if it kinda did it all for you on the fly (I'll have to read up when I get to that point).

I'm not terribly keep on having multiple DOS partitions, although that technically would work. Just always scares me. It's just temporary for the next 8 months anyway while we migrate to NAS from OES, but I'm running out of space and am on an unsupported OS anyway.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Rolling Cluster Upgrade (OES2 to OES11) - GPT partition

kjhurni wrote:

> Is there a better way vs. Pool Move that doesn't require massive
> downtime (in other words, the "other way" having the massive downtime,
> not the Pool Move).


There is nothing wrong with nvlm pool move. It takes some time, but does
not require downtime, and the whole operation might be scheduled for a
time with low traffic and load.

> Choice A = Pool Move = No downtime
> But let's say that's not a good option (for whatever reason) and someone
> says use Choice B. But Choice B ends up requiring downtime (like the
> data copy option).
>
> I just didn't know if Pool Move required that you create the partition
> ahead of time (so you can choose GPT) or if it kinda did it all for you
> on the fly (I'll have to read up when I get to that point).


No, it is done step by step: first create a new device on your storage
system, attach it to your OES servers, initialize it with GPT or DOS
table for sharing, then do the pool move command to mirror the existing
NSS pool to the fresh device.

> I'm not terribly keep on having multiple DOS partitions, although that
> technically would work. Just always scares me. It's just temporary for
> the next 8 months anyway while we migrate to NAS from OES, but I'm
> running out of space and am on an unsupported OS anyway.


For me pools which spread out on multiple devices do work nicely. But I
do agree that having one pool on one device is a cleaner setup that will
easier to work with. BTW, I never had issues with DOS and GPT devices on
the same NCS servers.

Günther

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.