|
One of the sales guys came to be with an interesting idea today that I don't think is possible, but we'll see. He he has a client that has a number of low/mid/high tier FC storage systems, some nonames, some 3par, etc. He wants to create a vSphere VSAN cluster to act as a front end for all of this storage. 60% of the hosts attached to this storage, about 6-8 different storage systems, all of different types, are ESXi of some sort, but the remaining are physical boxes, mostly oracle DB servers. His plan is to somehow create LUNs on the vSphere VSAN that can be presented to the physical devices through the FC network. I had not heard anything about this with the developments of VSAN, so I'm skeptical, but I really only deal with our IBM V7000s so my storage experience isn't very widespread. I had suggested some kind of storage visualization appliance, like the IBM SVC, but cost is a big factor so they're trying to do this on the cheap (big surprise.) Any ideas if there is any substance here? EDIT Definitely not possible. Virtual SAN supports only SATA, SAS HDD, and PCIe storage. You cannot use storage attached through USB, Fibre Channel, or iSCSI. mattisacomputer fucked around with this message at 01:00 on May 14, 2014 |
#
¿
May 14, 2014 00:14
|
|
|
|
| # ¿ Apr 25, 2024 02:02 |
|
|
For actual production use, vSAN is definitely demanding. I think it was in this thread but just a few weeks/months ago where someone had a catastrophic vSAN failure where a SAS controller couldn't keep up with a basic amount of vSAN i/o, even though the SAS controller was specifically on the vSAN HCL anyway. Home lab though? Yeah probably any ol' 6gbps SAS controller will do.
|
|
#
¿
Aug 17, 2014 20:27
|
|
|
Cenodoxus posted:
Won't happen, C# client is dead. vSphere 6 has an offline version of the webclient for ESXi host management without vCenter.
|
|
#
¿
Oct 1, 2014 19:07
|
|
|
Need some help, having weird latency issues with our iSCSI SAN. We've had both Dell and VMWare look at it, and they haven't found anything so far, but we haven't really pressed them yet. So far they're just pointing the finger at each other. Storage: Dell MD3220i, full of 7.2k 1TB disks, grouped into 5 disk RAID 5 arrays (3 arrays total.) Switches: HP ProCurve 2510s (Original), now HP ProCurve 3800s. Jumbo frames enabled and disabled. ESXi Hosts: Dell R620 and R710s, Customized Dell ESXi 5.5 with updated NIC drivers. Across all datastores we're seeing spikes of up to over 500ms read/write latency on the active storage paths. So far we've checked/tried the PSP (now configured to Round Robin), the problem started with Jumbo Frames enabled, they're now disabled for troubleshooting at Dell's request, the MD3220i is running the latest firmware. We've swapped out the ProCurve 2510s for 3800s, updated the firmware on both, updated the firmware on the Dell hosts, etc. Each path has it's own VLAN on the switches. Everything's been rebooted and we can't find any correlation between specific VMs / datastores / paths.
|
|
#
¿
Oct 12, 2014 16:40
|
|
|
Martytoof posted:I don't have any specific suggestions for your problem, but for the love of god please set up a bridge and have Dell and VMware join it together so they can fight it out themselves. You will get nowhere fast if you act as the go-between because it will literally be an endless fingerpointing circle, as you're figuring out. I agree completely, going to try to do that this week.
|
|
#
¿
Oct 12, 2014 16:49
|
|
|
Cidrick posted:Try to catch it while running esxtop (and press D for disk mode) on one of your ESX hosts and find out which LUNs and/or devices are generating the high DAVG/KAVG during periods of high latency. If the latency shows up as DAVG (which is what it most likely is) you can prooobably rule out VMware as a culprit, and then you'd have to look at the individual pieces of your physical path from there. Since this is iscsi, you can also try setting up a port mirror on your switches for one of the problematic hosts and set up a tcpdump/wireshark on the mirrored port to watch the conversation and find out where in a connection the delay is coming from. Wireshark supports a native iscsi filter so it should be pretty easy to get only the traffic that you care about. I didn't know wireshark had a native iSCSI filter, but I've been meaning to shark the traffic next time I was onsite, however this just proves I should have done this much sooner, thanks!
|
|
#
¿
Oct 12, 2014 19:15
|
|
|
Syano posted:Thats not a lot of spindles at all for a 3200i devoted to any sort of workload and they are slow spindles to boot. Are all the raid groups owned by the same SP? Do you even have multiple SPs in the chasis? What sort of workload are you putting it under? And are the extreme latencies seen all the time or under certain conditions. My gut tells me you should have just configured the thing as one huge raid group with a couple hot spares because this is probably where your latency is coming from. Agreed, here is more info based on your questions and others. The MD3320i has both controllers online, and the LUNs are spread evenly amongst the two. Correcting my earlier post, there are 24 total drives in the chassis, arranged into 3 RAID5 groups of 7 drives, segment size is 128KB. There are 15 virtual disks, spread roughly evenly amongst the 3 raid groups (5 VDs on array 1 / 6 VDs on 2 / 4 VDs on 3.) The workload is a general ESXi cluster, with mostly file storage and general application usage. Only one DB server, a SQL2k8 R2 box hosting vCenter/viewEvents/VUM. Latencies are all the time, and are even worse under heavy load - i.e. snapshot backups by Veeam, or just taking a regular snapshot in vSphere. Also, the latency just started 4-5 weeks ago. Previously backups were saving at over 50MB/s, now they're struggling to top 10MB/s apparently. The latency is also the same for all 4 hosts and 15 datastores, all of them are reporting the same spikes in read/write latency.
|
|
#
¿
Oct 12, 2014 19:23
|
|
|
adorai posted:Sounds more like a disk going into heroic recovery to me. Not sure what kind of individual disk stats you can get out of a dell md32xx array, but if there is any way to see disk read or checksum errors, I would be looking that direction personally. Doesn't look I can find any individual disk stats, but I could be missing something. We've tried two different pairs of switches. Originally we had ProCurve 2510 Gig switches which have worked fine since the environment was stood up over 2 years ago at this point. There are four different storage VLANs creating four different paths for each host to the storage. We've subsequently replaced both 2510s with 3800 series ProCurves and set them up the same way, four different VLANs, each port is only tagged on one VLAN and there are no trunks. Everything negotiated at Gig fine on both pairs.
|
|
#
¿
Oct 15, 2014 17:59
|
|
|
Anyone here using the NVidia GRID K1 or K2 in production? We're starting research now but the idea is to buy two hosts with K2 cards to be VDI hosts for a computer lab and use the SGA option. Just curious what you guys have seen with them and if they make a difference for basic workstation uses that benefit from hardware acceleration, like Flash, etc, and more advanced stuff like Google Earth.
|
|
#
¿
Feb 1, 2015 17:45
|
|
|
|
| # ¿ Apr 25, 2024 02:02 |
|
|
Awesome, I appreciate the feedback. Was that with the K1 or K2 card? Also what brand of severs did you use?
|
|
#
¿
Feb 3, 2015 16:50
|
|