My preference on software defined (storage) solutions is not a big secret any more, nevertheless it gets frequently a new spin. Recently so, we observed some strange behavior on our storage leaking over into the corporate ERP systems but primarily caused by our VDI environment and some write patterns showing up there.
Starting to think over the solution space, the typical suspects of course didn’t hesitate to offer 6-digit priced all flash storage systems to leverage the issue. Not exactly the type of budget I want to request for a unforeseen development in systems usage (besides all the foreseen changes and projects).
But did anybody reflect over the latest development in CPUs, PCI- buses and SSD/NVMe? I started to munch further down the isle reflecting over a couple of things:
Reloading a VSF cluster of Aruba switches, as in the firmware upgrade procedure discussed, is not obviously running straight forward. Since I tried to google a couple of times and really found no straight comment on what actually happens, here the summary of my findings.
Long story short. A warm boot with reload does not result in a predictable successfull manner. Never. Nowhere. That`s it!
The often cited vsf sequenced-reboot is only supported on the 5400 platform. So all the kind remarks for users with 2930F, 3810 or similar VSF enabled platforms are simply not helpful. Continue reading →
Considering recent posts on IRF, there was a need to get some availability with the more cost effective switches from the Aruba / ProCurve world. I did some research on that and luckily there are more than one option today with this platform – at least the 5400s (…) and in my case 2930s support this by default.
Considering redundancy you basically consider two types of high availability and these cover Layer 2 availability, traditionally suited with link aggregation which conventionally does not span several chassis, and Layer 3 availability for a redundant default gateway service.
In a traditional design, then with a couple of switches (at least four), you configure VRRP for L3 redundant default gateway service, LACP – link aggregation groups for L2 Continue reading →
Some time ago, I posted on the configuration of an IRF independent resilient fabric with the HPEFlex Fabric FF5700 datacenter switches. During the operation some things arose to my attention which either have been corrected or perhaps not necessarily clear from the first place.
1.) Activate MAD
There needs to be a mechanism to detect multiple actives. This could be considered something like a quorum for the switch-cluster, intended to prohibit split brains. In my case I preferred to do so with LACP. This brings MAD (Multiple Active Detection) to the layer two and is rather simple. It should be configured on an appropriate Bridge Aggregation Group – resulting in an configuration like:
port link-type trunk
port trunk permit vlan all
link-aggregation mode dynamic
Konkret sieht die Installation der Software zur Storage Virtualisierung wie folgt aus:
Ich installiere zuerst auf zwei Hosts vmWare vSphere 5.5 und lizenziere diese mit Enterprise Plus. Danach installiere ich einen vCenter Server – oder nehme denjenigen, der in meiner Umgebung zur Verfügung steht. Die VMWare Installation lasse ich an dieser Stelle außen vor – zu berücksichtigende Konfigurationen oder Ausstattungen folgen später im Thread.
Drittens installiere ich die VSA Appliances mit dem entsprechenden Installer. Auch hier fasse ich mich recht kurz, da das zuvor schon gepostet wurde.
Hierbei sind im Wesentlichen drei Dinge zu beachten: