SOLVED
The P2000 itself does not support SSDs at all.
The P2000 is available with FC, SAS and iSCSI connectors, even a mix of FC and ISCSI. There is also a P2000 disk chassis with I/O modules only (no controllers), used as an extension.
You need such extension chassis if you want to increase capacity, you cannot "daisy chain" two P2000 disk arrays (or newer models).
If you use SAS connections, only a few specific HBAs are supported, they cannot use their own cache.
All the details here:
https://www.hpe.com/h20195/v2/GetPDF.aspx/c04168365.pdf
Hope this helps!
Regards
Torsten.
__________________________________________________
There are only 10 types of people in the world -
those who understand binary, and those who don't.
__________________________________________________
No support by private messages. Please ask the forum!
If you feel this was helpful please click the KUDOS! thumb below!
Thank you for the detail. If I understand your request, you are trying to decide betwen:
1) Upgrading the P2000 to MSA 2042 (or replacing the P2000 with MSA2042)
2) Beefing up the local storage in the servers and using them without the MSA
Either option is fine but, as you pointed out, there are disaster recovery benefits with using the MSA as shared storage with the ability to vmotion VMs between hosts and use VMWare HA feature.
So, for the sake of this discussion based on the information you've provided, let's assume you are looking to do the following:
1) Move to a current MSA model with caching and/or tiering. You don't care about any of your existing data, you simply want to be able to use your existing 11 x LFF SAS drives and rebuild a new MSA system with virtualized storage, tiering, and caching.
In this case, I would:
a) Purchase an MSA 2052 with the desired support and SFPs (do you need 1GB RJ45 SFPs?)
https://www.hpe.com/h20195/v2/GetDocument.aspx?docname=a00008277enw
b) Configure the MSA as desired
c) Move your drives over
d) The MSA 2052 would ordinarly recognize your data but will not support it in this case because you are using Linear volumes. So, since you don't care about the data anyway (as you mentioned), blow away and reconfigure your disk groups, volumes, and restore data
e) Since you such a limited number of disks, you'll need to carefully plan your pool assignments. If you wanted to do tiering, rather than caching, then all your disks would need to be in the same pool to effective use the limited drives you have. In this case, one controller will essentially be serving up all the data and the other would be a failover. If you had a lot of disks, you could spread it out a bit more. This likely won't be a performance issue with your configuraiton. If you truly want to do caching, you have some more flexibility because you could assign the NL and 1 SSD in one pool and the 15K and SSD in another pool.
f) consider purchasing at least one more 3TB drive and using it as a spare. You are asking for some trouble by using RAID5 on NL disks and having no spare. RAID6 is recommended on NL disks due to lower MTBF and longer rebuild times.
At the end of the day, you could also look at purchasing controllers (and maybe advanced data service licensing) and upgrading your P2000 shelf. However, chances are you might be out of warranty on your P2000 and just buying a brand new empty shelf might be the cleanest and most cost effective way to deal with this. There are lots of variables here and way more questions and answers that should be shared than can be efficiently communicated over a message board. I would suggest working with a qualified HPE partner (VAR) in your area who has Solution Architects on staff who can take some time and really dig into your requirements so that you get the most cost effective solution and don't have any surprises.
I work for HPE. The comments in this post are my own and do not represent an official reply from the company. No warranty or guarantees of any kind are expressed in my reply.
Chris,
The MSA 2050 series will eventually replace the 2040 series so they should be roughly the same cost. 2050 series is not considered a higher level model (though does have some improved specs) but rather the next lifecycle generation.
I'm not sure when they will be available in Greece. However, if all you can get is the 2040 series and you need to act quickly, then that is fine. You'll have many happy years on the 2040 series.
The MSA 2040/2050 series has four available ports per controller. A host should always be hooked to at least one port on each controller for failover capability. This gives you a maximum of four connected hosts (in a direct connect scenario). Obviously, many more hosts when using Ethernet or FC switches.
You can make two ports on the controller be iSCSI and two be FC (mixed) if you wish. Of course, you can also do all four ports as the same protocol. You can only present a volume to ports belonging to the same protocol type. So, a single volume is presented to iSCSI or FC hosts but not both.
You cannot directly attach a P2000 controller shelf to a MSA 2040 series controller shelf. You would first need to replace the controllers with Disk I/O modules. If you have a LFF shelf then the disk IO module is part number AP844B and you'll need two along with two SAS cables. If your P2000 base shelf is a SFF shelf then you cannot replace the controllers with disk I/O modules and you'ld need to buy a new drive enclosure shelf instead.
Finally, regarding tiering vs. caching; performance benefits depends on your specific workloads. Tiering affects reads and writes, caching affects reads. So, heavy read workloads do well with caching. If you have tons of archival data then tiering can make sense because all your stale stuff can eventually make its way down to NL disks and you grow capacity by adding NL. No data is ever pinned to caching disks so no need to protect it. Hence, a minimum of 1 per pool can be used. Data is pinned in tiering so you need to protect it. Therefore, a minimum of 2 SSDs per pool (in RAID1). In your case, if you are going to use tiering, just place all your disks in the same pool since you don't have that many.
Best of luck!
I work for HPE. The comments in this post are my own and do not represent an official reply from the company. No warranty or guarantees of any kind are expressed in my reply.
Chris,
No problem :)
Sounds like you are coming up with a good plan. Tiering only works within the same pool. So, in your case of limited disks, you'd want to create a RAID1 SSD virtual disk group assigned to pool A (and controller A), a RAID10 SAS virtual disk group assigned to pool A (and controller A), and a RAID10 MDL virtual disk group assigned to pool A (and controller A).
Spreading out your disk groups amongst the two pools (and thus controllers) is a general best practice for getting the best possible performance. However, you'd need a minimum of two more SSDs to create a RAID1 performance tier for pool B. Even then, now you only have 4 SAS and 2 MDL disks ever handling a request in a given pool. Of course, I can't be 100% sure, but I think your configuration would be best served by dumping everything in single pool. Controller A will be the only one working however, controller B will be available in a failure (as long as each host is connected to each controller). With your disk config, I think you have plenty of controller headroom so as to not really see the benefits of spreading out over both pools/controllers.
A couple final notes:
1) Direct Connect
I know you said you were doing FC direct connect now and considering iSCSI direct connect.
I'm finding mixed info, at this time, as to whether it is officially supported. HPE SPoCK indicates iSCSI direct connect is not supported and web searches indicate that it is VMWare themselves who don't support iSCSI direct connect. I can't find anything definitive but am leaning towards it not being supported at this time (even though it may tecnically work).
2) Converting your shelf/moving drives
Consider the following PDF https://www.hpe.com/h20195/v2/Getdocument.aspx?docname=a00015116enw
Note the table on page 4. The MSA 2050 discontinues support for a lot of older hardware. Without extensively digging into this more, I am afraid that you may run into issues with your older drives or enclosure on an MSA2050. At best, you might be able to move your drives into a new MSA 2050 enclosure but you'd need to compare against the table.
Now, note the same document for upgrading to MSA 2040 series at https://www.hpe.com/h20195/v2/GetPDF.aspx/4AA4-6830ENW.pdf
I think you'll see that you'll have a much smoother experience trying bring older hardware over to an MSA 2040 series array. So, sorry for the initial recommendation to try MSA 2050. If this were net new then MSA 2050 would be best bet. Upgrading, MSA 2040 series will be a better bet for your use case.
Best wishes.
I work for HPE. The comments in this post are my own and do not represent an official reply from the company. No warranty or guarantees of any kind are expressed in my reply.
Chris, the 6G SAS drives will be your limiting factor as they are not supported in the MSA205x in any enclosure. As long as your drives are SAS, and not SATA, you should be good to go on the upgrade to MSA 204x.
Good luck on your project.
Mike
I work for HPE. The comments in this post are my own and do not represent an official reply from the company. No warranty or guarantees of any kind are expressed in my reply.
Chris, the SFF D2700 shelf itself supports 6G and 12G drives. The drives that are currently sold and qualified for the MSA 20xx, in the D2700, are all 12G drives. As per that document, 6G drives are not supported in the MSA 2050, regardless of what enclosure they are installed in. If you'd like to private message me your e-mail address, I can take this offline and see if I can connect you with your local HPE account team who may be able to help you with this further.
Thanks,
Mike
I work for HPE. The comments in this post are my own and do not represent an official reply from the company. No warranty or guarantees of any kind are expressed in my reply.
Chris,
The presence of an A, B, etc on the end of a part number usually indicates that it's different lifecyle generations of the same product. The A and B units *should* be functionally equivalent but had different introduction and discontinuance dates. Please note that I/O module for this enclosure is no longer available for sale as a new part from HPE so I would expect you would need to source the modules, and/or shelf w/modules, via a used/refurbished route.
Thanks
Mike
I work for HPE. The comments in this post are my own and do not represent an official reply from the company. No warranty or guarantees of any kind are expressed in my reply.
Hi Chris,
Congrats on your upgrade and glad that things seem to be working out to your liking. I'm curious though. By putting your nearline disks in a seperate pool, they are not part of the tiering strategy on Pool A. This means that cold data can never migrate all the way down to the nearline disks. Certainly OK if that is your intention.
You also said that all your hosts are connected to just the first controller (assuming controller A). This would typically mean that your hosts wouldn't have access to volumes on Pool B (if using ALUA) since Pool B should be owned by controller A and you say your hosts don't have access to controller B. So, If this is truly the case then you are probably sending IO (to the controller B) volumes via controller A. This is considered a non-optimzed path and will increase the backend IO between the controllers and potentially decrease performance.
All in all, it sounds like you have this working some way that you are happy with but just a couple of notes I thought of.
Take care,
Mike
I work for HPE. The comments in this post are my own and do not represent an official reply from the company. No warranty or guarantees of any kind are expressed in my reply.
Thx mike, your help was invaluable believe me
Now
Congrats on your upgrade and glad that things seem to be working out to your liking. I'm curious though. By putting your nearline disks in a seperate pool, they are not part of the tiering strategy on Pool A. This means that cold data can never migrate all the way down to the nearline disks. Certainly OK if that is your intention.
Yes i did that after big thought because i have the HP 81Q cards at this momment and with this in mind my 4 hosts need to be fast in PoolA where the VM system disks relies and also the SSD disks for performance.
Also i didnt want to raise the Usable space of the PoolA because then the 2 SSDs that give me 400GB are not enouph according to HP, to get good performance from tiering. You need to have 10% of usable space at least( i know its not holy grail but i respected it), so if i had put the 4 x MDLs in PoolA suddenly from 2.8TB usable space i would had gone to 8.8TB usable space all in Pool A with under 5% of SSDs for performance tiering. I also considered the scenario to brake the 4 MDL's with 2 in POOLA and 2 in POOLB but with that way i loose disk speed since the more the disks together the faster througput you get.
Also the MDL disks contain only SMB data (and backup space that is workign in nights) which in my case are accessed by Windows Terminals (virtual or Physical) that dont need extra speed for this. From test as we speak i get 100MB/sec or more speed from the MDL's which is totally acceptable (with the P2000G3 i was getting under 60MB/sec). If i buy 2-3 more SSD's to make the POOL A bigger in performance tiering then i will reformat everything and redo all the work but i really dont think is needed.
I include a screenshot of the speeds that i get from HD Tune.
The left image is from a System disk of a server that relies on the POOL A and the 2nd is from the SMB Server that uses the MDL's in POOL B (i didnt had any other way to measure speed.. if there is i am willing to do tests for sure)
You also said that all your hosts are connected to just the first controller (assuming controller A). This would typically mean that your hosts wouldn't have access to volumes on Pool B (if using ALUA) since Pool B should be owned by controller A and you say your hosts don't have access to controller B. So, If this is truly the case then you are probably sending IO (to the controller B) volumes via controller A. This is considered a non-optimzed path and will increase the backend IO between the controllers and potentially decrease performance.
Yes this is the case. All my hosts are in 1st controller and to access the 2nd Pool controller A gets what it needs from controller B. I know this is not optimal but works and the speed penalty is not big in my scenario. For a moment i thought creating a Linear group of the MDL's and assign it to Controller A but then i decided to use the 2nd controller even like this, because we must not forget that the 2nd controller has extreme fast cache and with that way is usable (i hope i am not wrong).
Generally i plan to buy more disks and i am thinking
A. 2 x 400GB ssd's and i will use all 4 and in the end i will get 800GB performance tier space where i have a raid question atm :-). Question is when i buy the 2 SSD's i just create another raid 1 in pool A or i delete the 1st SSD group that i have atm and with the 4 SSD's together i create a new Raid10 (or raid 5 maybe)? is there any performance gain doing this?
B. 8x600GB SAS to add them in PoolA. Question here is if i really need to buy 15K disks since my 1st 8x600GB disks are 15k. I know HP says is supported but its better not to mix different speed disks in same Tiering. Maybe i can buy 8x600 10K disks and assign them as Archive tier in POOL A.
Thx for your notes and help really... i will reconsider some things for sure.
Kind Regards
Chris
Hi Chris,
I'd be curious to see those Pool B test results with hosts having direct access to controller B. It would be interesting to see what the true penalty is for you of not using an optimized path. Ideally you should consider getting addition FC cards in each server or replacing with 2-port cards. In your case, having only a single 1-port card in your servers will cause a complete outage if Controller A goes down. Also, it prevents you from ever doing an online firmware upgrade on the MSA (which is possible if hosts have access to both controllers). Anyhow, that is a side point.
Your question 1:
If you are going to buy 2 more SSDs for Pool A then you can simply add them as another RAID1 group and the system will take care of everything for you. That is the beauty of pools and wide striping. If you wanted to reconfigure to RAID 5 then it would be destructive (you'd have to move data off the array and back on). Using RAID 5 will give you better space efficiency (you'll loose drives worth of space instead of 50% as in RAID1). This can be highly desireable with the cost of SSDs. With any parity based RAID (5, 6), you will suffer a performance penalty on writes over RAID1 but probably not enough for you to notice in your enironment. Most customers will use RAID 5, 6, or some variation thereof on SSD in order to get better efficiency but certainly nothing wrong with RAID1/10. In your case, if you're going to stick with mirrored drives then simply add another RAID1 disk group to the pool and let the array take care of rebalancing. If you wanted to set the four drive up as RAID10 then it would be destructive (like RAID5) and you wouldn't gain anything in the end.
Your question 2:
The MSA sees SSD as a "performance tier", 10/15k as a standard tier, and 7.2k drives as an archive tier. There is no way around that. So, if you add 10k drives to your Pool A then the MSA will treat that as an addition to your 15k "standard tier". You can certainly add 10k drives to your 15k pool but it isn't "recommended". Whenever you add different size, or speed, drives to your pool (or wildly change the RAID characteristics of vdisks within it) then you introduce the potential for inconsistent performance results in the pool. Will it be noticeable in your case? hard to tell but you should be aware of the potential and do your best to try and keep to best practices.
Take care,
Mike
I work for HPE. The comments in this post are my own and do not represent an official reply from the company. No warranty or guarantees of any kind are expressed in my reply.
Chris,
RAID 10 is mirroring and striping. With thin provisioning, and pools, on the MSA mutiple RAID1 vdisks are striped (or wide striped) via the array controller virtually chunking up the volume instead of it being done purely at the RAID level. So, performance should be similar regardless of whether you have a RAID10 VDISK or multiple RAID1 VDISKS backing the same pool. I supposed you'd really have to run an exact test to tell but I don't think it's worth the effort.
Regarding your other question, you should be able to remove a vdisk so long as the pool as enough space to survive the removal of the vdisk. This will kick off a VDRAIN process and will take time.
and page 148 of
http://h20564.www2.hpe.com/hpsc/doc/public/display?docLocale=en_US&docId=emr_na-c04957376
I work for HPE. The comments in this post are my own and do not represent an official reply from the company. No warranty or guarantees of any kind are expressed in my reply.
Hi Chris,
You cannot present the same volume to both iSCSI and FC ports; it's one or the other.
Also, be careful on your iSCSI (Ethernet) hookups. Directly connecting a VMWare host to the MSA is not supported like it is with FC. You'd need an Ethernet switch.
I work for HPE. The comments in this post are my own and do not represent an official reply from the company. No warranty or guarantees of any kind are expressed in my reply.