If so you might want to put that in its own pool instead.
1.) When in the same pool the data will be striped between the members in proportion to their relative sizes. So the larger member will hold more of each volume data in your case.
2.) If one member in that pool goes down, all the volumes in common will go offline until the failed member is restored.
3.) If you are mixing drive speeds you might do better focusing the critical volumes on that member. Depending on IO requirements possibly use RAID10.
You will at some point soon want to upgrade the original member to 10.0.2. as well.
If you do decide to move it to the default pool, the process will show completed very quickly. In the background the data will be distributed to the new member.
That new member is a hybrid designed for low latency. That you are stripping to a slower array with more capacity.
You can always merge them later, but doing the opposite is a more involved, longer process and you must have enough free space on the larger member to store the data from the new one.
You can move volumes from the 7200RPM array to the hybrid live w/o downtime.
Make sure you switch has enough inter switch bandwidth to support the additional array.
A empty pool or the one which you use for maintenance
Ping all iSCSI Network Interfaces . Perform a CM failover to check also the standby Network
Update all members to the same FW
Than you can move the new guy into your production pool. But in YOUR CASE i highly suggest to place your Hybrid EQL into a dedicated pool because of the huge speed difference combined with the larger PS6100E the EQL Loadbalancer will place more data on the old and slow member because of the larger capacity.
Pro: They would work together on all volumes in that pool. All volumes by default spread across both members. The amount is proportional to how big each one is in comparison to the other. So if one is twice as big, it will hold 2/3 of the data for each volume.
Con: If one member fails, all volumes they have in common will be offline until the problem is resolved
The particular 'con' is your case is the Hybrid array. It's faster but to complete each server IO, both will have to process their share of the data. The hybrid will do it faster of course. But server won't see that until the NL-SAS member finishes.
If that slower member gets behind it will move busy pages to the hybrid for idle pages on the hybrid.
Given the expense of the hybrid, and usually bought for specific role. SQL, VDI, Exchange it's best to put it in its own pool. At least to start. You can move volumes from the NL-SAS array to the hybrid at any time, live.
If you have SANHQ you can see what your current load and IO patterns are and help move volumes needing the lowest possible latency to the Hybrid. This also improves the NL-SAS array's performance too.
Later you can always merge them. That's easy. Going other way is long and time consuming assuming you have the free space to do it later.
dwilliam62
6 Operator
•
1516 Posts
•
6374 Points
1694
0
Posted March 8th, 2019 12:00
Hello,
That new member, are those 10K or 15K RPM drives?
If so you might want to put that in its own pool instead.
1.) When in the same pool the data will be striped between the members in proportion to their relative sizes. So the larger member will hold more of each volume data in your case.
2.) If one member in that pool goes down, all the volumes in common will go offline until the failed member is restored.
3.) If you are mixing drive speeds you might do better focusing the critical volumes on that member. Depending on IO requirements possibly use RAID10.
You will at some point soon want to upgrade the original member to 10.0.2. as well.
If you do decide to move it to the default pool, the process will show completed very quickly. In the background the data will be distributed to the new member.
Regards.
Don