Timing of adding node

In addition to those questions that need to be answered, I've found it fairly inefficient to add only 1 node at a time.

With 2:1 protection, you should add nodes in multiples of 3.  With +2 protection, you should add in multiples of 4.

The rationale is that if you're running out of space, you will not help much by adding only a single node since writes still have to go to the rest of the cluster until the space is balanced (which can take weeks in some environments).  If you add 3 nodes at a time, then all new writes can be sent to the new nodes.

Hi Ayas,

Thanks for your question. I probably don't have the full answer but wanted to add a little to it. This sounds like the customer wants to know when to add a node to an existing Isilon cluster based on CPU usage. Is that correct?  While I agree that CPU usage is an important consideration, the question should be expanded to include more considerations than just CPU usage. For example:

How much unused disk space is available?

How fast is existing storage being used?

Are there any network interface bandwidth problems?

Does the customer have "peak" times for storage needs, such as heavy storage access when creating end-of-month reports?

Has the customer's workflow changed since the original implementation or latest update to the cluster? (Maybe the customer needs a different tier of storage in addition to what they are already using.)

The customer might benefit from a PS engagement known as "Isilon Configuration Assurance". (Disclosure: I develop Professional Services offerings for Isilon.)

In summary, it sounds like this conversation could (and should) be moved from commodity purchase, based on Isilon node CPU usage, to a periodic solutions-based discussion.

Kind regards,

-Marvin Harris

> The rationale is that if you're running out of space, you will not help much by adding only a single node since writes still have to go to the rest of the cluster until the space is balanced (which can take weeks in some environments).  If you add 3 nodes at a time, then all new writes can be sent to the new nodes.

I don't know of any optimization in OneFS that works like this.  If you're using FEC, and the file is large enough, and there is free space elsewhere on the node pool you're writing to, blocks will still go to the "old" nodes, in addition to the newly added nodes.

It's certainly true that OneFS will prefer nodes/drives with more free space, but not at the expense of writing a stripe inefficiently.

Ed, I see what you are aiming at... but wouldn't that take just "batches of at least 3" rather than "multiples of 3" (= 3, 6, 9)?

(or 4 for +2 protection resp.)

-- Peter

hi ed and kipcranford

Thanks for the comment , Right,,,it is depends on how cluster configured ,,,Adding one node may not worth whole...

thanks !

aya

Hi harrim10

Thanks for the reply , you are right there are so much factor involved ....That is why he asked this question to start with .

I may suggest him to your  suggestion they may need to take ...

Thanks heaps!

aya

HI everyone,,,,

FYI ... I just had some idea from other user about CPU usage and Node .

Note that this is not official and just for this particular user .... he has line with 60% usage as It will be

Average of  30% CPU usage for jobs with Impact Policy set as Medium ( like FlexProtect)

and leave some extra for unexpected ...