Samstag, 21. Juli 2012
Bedingt durch eine Useranfrage per Mail und einen Forenbeitrag, möchte ich ein paar Worte zu Continuous Access EVA, seamless Failover und VMware verlieren. Folgende Aussage stand durch den Forenbeitrag im Raum:
Failover ohne das ein System irgendwas merkt, bekommt man bei HP gar nicht hin (selbst HP Techniker mussten vor dem HP Vertriebler einknicken und gestehen, das man manuell eingreifen muss).
Diese Aussage ist definitiv falsch. Zum einen gibt es die HP Cluster Extension EVA, mit der man Failover-Szenarien in Clustern automatisieren kann, zum zweiten kann man sich VMware vSphere hier mal genauer anschauen. Die Frage, ob automatisierte seamless Failover ein erstrebenswertes Merkmal von HA-Lösungen sind, lasse ich an dieser Stelle unkommentiert... Wenn bei einem Failover (geplant oder ungeplant) die Destination Vdisks aktiv geschaltet werden, dann sieht VMware vSphere erstmal die gleichen Disks. Die Vdisks sind identisch mit den Source Vdisks. VMware vSphere wird aber zu einer kleinen Diva, sobald sich Metadaten am Volume ändern. Das können z.B. LUN ID, SCSI Inquiry String oder WW LUN ID sein. Erkennt das System hier Abweichungen zwischen den Metadaten im Volume und den ermittelten Daten der Disk, dann geht das System davon aus, dass man ihm einen Snapshot präsentiert und nicht das echte Volume. Zum Glück wurden LVM.DisallowSnapshotLun und LVM.EnableResignature mit ESXi4 entsorgt... Was passiert denn, wenn sich LUN ID, SCSI Inquiry String, WW LUN ID (also die Metadaten) bei einem Failover nicht ändern? Genau, es passiert nichts. Der Kram läuft weiter. Sofern man einen Failover zwischen zwei EVAs mit dem gleichen Controllermodell macht und die Destination Vdisks mit der gleichen LUN ID präsentiert sind, dann passiert nichts, es läuft einfach weiter. Für VMware ändert sich, bis auf die Pfade zum Datastore, nichts. Wer eine EVA mit CA hat, kann das anhand einer kleinen Vdisks und einer separaten DR Group mal testen.
Montag, 11. Juni 2012
Relativ still und leise hat HP die P6000 Modellreihe aktualisiert. So gibt es nun die EVA P6350 und HP EVA P6550. Zu den Neuerungen zählen ein doppelt so großer Cache (8 GB bei der P6350 und 16 GB bei der P6550), ein schnelleres ABM Modul, neue Cache-Batterien und ein neues XCS 1010 0000. Bedingt durch den größeren Cache kann die P6350 nun ca. 800 TB, die P6550 ca. 1,2 PB an Speicher adressieren. Mit dem neuen XCS wird auch endlich VMware VAAI unterstützt. Da dies aber eine Funktion der Firmware ist, sind die alte P6000 Modelle selbstverständlich VAAI kompatibel, sofern die neue XCS Version eingesetzt wird. Hinter den Produktnummern QR556A und QR557A verstecken sich die entsprechenden Upgradekits für die P6000 Modelle (Cache, Batterien, ABM Modul und neue Frontabdeckung). Vor dem Upgrade ist aber ein XCS Versionsupdate notwendig. Angesichts der eher geringen Änderungen und des Preises von ca. 3.500 € bis 5.000 € (LP) kann jeder selber entscheiden, ob das Upgrade unbedingt sein muss.
Passend dazu passt die Ankündigung, dass die HP EVA 4400/ 6400 und 8400 Ende Februar bzw. Ende Mai EOL gehen. Add-Ons und Upgrades lassen sich noch bis Mai 2012 ordern.
Samstag, 15. Oktober 2011
Passend zum neuen XCS Release hat HP eine neue Version der HP P6000 Command View Suite veröffentlich. Mit dabei ist nun die HP P6000 Performance Advisor Software, eine Performance Management Komponente, welche sich nahtlos in Command View EVA integriert. Dafür ist allerdings eine array-basierte Lizenz notwendig. Der Support für die EVA GL Serie ist übrigens entfallen! Wer also noch EVA 5000 oder EVA 3000 Systeme im Einsatz hat kann die neue Version von Command View EVA nicht einsetzen. Dafür lassen sich nun ABM Installationen mit managen, eine echte Erleichterung bei größeren EVA Deployments mit vereinzelten ABM Setups. Die Neuheiten lassen sich den Release Notes entnehmen. Die Software selber gibt es wie immer kostenlos im Software Depot. Weitere Infos findet man in den Quick Specs.
Samstag, 15. Oktober 2011
Nachdem die neuen P6300 und P6500 mit XCS v10001000 ausgeliefert werden, hat HP nun das neue XCS Release auch für Endkunden verfügbar gemacht. Die neue XCS Version kann kostenlos im Software Depot bezogen werden. Grundvoraussetzung ist eine supportete EVA Plattform und min. Command View EVA 9.4. Passend dazu gibt es aber nun auch Command View EVA 10. :) Wie man den Release Notes entnehmen kann wurden in dem Release wieder mehrheitlich nur Bugs gefixt. Wie immer wird allen Kunden zu einem Update geraten. Ob das wirklich notwendig ist, sollte von Fall zu Fall entschieden werden. Never touch a running System. ;)
Sonntag, 10. Juli 2011
HP empfiehlt für die Installation von Command View EVA eine englische oder japanische Version des Betriebssystems, und das offenbar nicht ohne Grund. Wer versucht Command View EVA 9.4 z.B. auf einem deutschsprachigen Windows Server 2008 R2 zu installieren, stößt auf diese Fehlermeldung:
The current user does not have administrator privileges.
Only a user with administrator privileges can run the Installation. Und diese Meldung kommt immer, egal ob mit UAC, ohne UAC, als lokaler Administrator, als Domänenadministrator, als irgendein Benutzer der in der Gruppe der lokalen Administratoren - total egal, sie kommt immer. Interessant dabei: Diese Meldung kommt i.d.R. nur bei nicht englischsprachigen Windows-Installationen. Es gibt dazu auch einen Eintrag in den Release Notes:
Upon starting the installation of version 9.4 (or upgrade from version 9.2 or 9.3), you may receive an error message that you do not have administrator privileges. To avoid this error message, ensure that you add your user name to the local Administrators group before starting the installation or upgrade.
Dazu gibt es auch einen Thread im HP Support Forum, wo ich u.a. die Lösung gepostet habe. Umgehen kann man diese Meldung, wenn man eine lokale Gruppe namens "Administrators" anlegt und dafür sorgt, dass der Benutzer mit dem man installiert, sowohl in der Gruppe der lokalen Administratoren, als auch in der Gruppe "Administrators" ist. Offenbar wird dieser Gruppenname hartkodiert abgefragt. Nicht wirklich sauber programmiert... Aber der Workaround funktioniert. Wer natürlich seine Server in englischer Sprache installiert, hat das Problem nicht.
|