Update VSphere 4.1 mit 3 ESXi 4.1 auf 5 frage zu VRanger

[JayDe]

Hallo erstmal, ich hoffe das Thema gab es so hier noch nicht bzw. über sufu hatte ich nichts Passendes gefunden.

Also das Szenario sieht wie folgt aus: Wir nutzen hier eine VSphere 4.1 umgebung mit 3 ESXi 4.1 Hosts diese soll jetzt auf V5 migriert werden. Das ist soweit kein Problem nur kenne ich mich leider nicht mit VRanger aus und hätte dazu ein Paar fragen.
Was ich gelesen habe, dass ich für jeden ESX eine Virtual Appliance brauche und diese bei Vranger registrieren muss.

Vranger ist übrigens die v 5.3.1 ...

Wie sieht das mit den Jobs aus die in der jetzigen umgebung laufen, müssen die nach dem anlegen der VA neu angelegt werden oder übernimmt er diese so?

Die VA gibt es so wie ich gesehen habe bei Quest als Template zum runterladen bzw. in der Software gibts den punkt "Deploy from Quest Home Page" wenn es das denn ist. Diese muss ja dann nur angepasst werden.
Muss man dort nach Konfiguration von DNS / IP / Hostname noch irgendwelche einstellungen tätigen?

Wie gesagt mein Kenntnisstand bei VRanger ist gleich null


Ich hoffe jmd kann mir da weiter helfen.

Grüße

Jürgen

[irix]

1. Akt. mal gleich auf vRanger 5.5 (Inplace Upgrade)
2. Jobs koennen unveraendert weiterverwendet werden sofern sie nicht die Methode "COS", welche es nur unter ESX gab, verwenden
3. Du darfst dir gerne die *.ovf in Version 1.5 herunterladen und selber deployen bzw. den mit der 5.4 eingefuehrten Wizzard verwenden. Letzter installiert auch automatisch die VMware Tools mit.

Trotz Wizzard muss man Hostname und IP Settings(Default ist DHCP) noch im GuestOS eintragen. Achtung.... engl. Keyboard Layout und somit Augen Auf beim Passwort!

Folgende Optimierungen sollte man machen:
- Upgrade auf akt. HW
- Je nach Anzahl an VMs welche man gedenkt per HotAdd zu sichern sollte man gleich einen 2. RAID Controller hinzufuegen.
- Wer selber deployed kann Thinprov. einstellen und spart so ca. 50% (6GB)
- Wer Replizierung macht muss die Scratch Disk anlegen. Macht das der Wizzard so ist der Name evtl. nicht der Namenkonvention entsprechend

Aber eigentlich muss man nur mal ein Auge in das PDF Werfen und man sieht das es kein Voodoo ist. Die VAs sollten per DRS Regel dem Host zugewiesen werden ansonsten schreibt man sich einen NAGIOS Check welcher prueft ob eine VA an ihrem Platz laeuft.

Wer nicht fuer jeden Host eine VA spendieren will kann auch eine VA fuer den ganzen Cluster bereitstellen. Die skallierung ist dann nicht ganz so gut aber je nach Bottleneck ja nicht das Thema.

Gruss
Joerg

[JayDe]

Vielen Dank das hilft mir schon weiter
Danke für die schnelle Antwort.

[JayDe]

Hallo Nochmal,

hab dazu noch ein paar fragen ...

Ich hab den VRanger jetzt auf 5.5 und das Vcenter ebenfalls auf v5.0ou1 die 3 VA´s habe ich nun auch angelegt und konfiguriert ...
wie sieht das jetzt in VRanger aus ? die einzelnen ESX-Host bleiben ja als Credential´s drinnen zwecks Lizens, oder?
Ich müsste ja nur im Backupjob bei Costum Transport selection umstellen auf Via VRanger Appliance und dann noch auf HotADD umstellen .. oder seh ich das falsch?
Mir erschließt sich sonst noch nicht wie die Appliance sonst arbeiten?!

Hoffe mir kann da noch kurz jmd weiter helfen

Vielen Dank schonmal
Grüße
Jürgen

[irix]

Hallo Nochmal,

hab dazu noch ein paar fragen ...

Ich hab den VRanger jetzt auf 5.5 und das Vcenter ebenfalls auf v5.0ou1 die 3 VA´s habe ich nun auch angelegt und konfiguriert ...
wie sieht das jetzt in VRanger aus ? die einzelnen ESX-Host bleiben ja als Credential´s drinnen zwecks Lizens, oder?

Das hat weniger mit der Lizenz zutun als das sich im Nofall der vRanger auch mal mit den Hosts direkt unterhalten moechte. Die Credentials nur ueber vCenter zumachen ist nicht genug und in der Praxis faehrt man besser auch bei den Hosts nochmal ein User/Passwort einzutragen.

Ich müsste ja nur im Backupjob bei Costum Transport selection umstellen auf Via VRanger Appliance und dann noch auf HotADD umstellen .. oder seh ich das falsch?

Wenn in den Jobs nichts expliziet konfiguriert wurde dann reicht es die globale präferierte Reihenfolge abzuaendern gemaess seinen wuenschen.

Mir erschließt sich sonst noch nicht wie die Appliance sonst arbeiten?!

Hoffe mir kann da noch kurz jmd weiter helfen

Vielen Dank schonmal
Grüße
Jürgen

Wenn lizenztechnisch HodAdd genutzt werden darf und die VMs auch nicht auf Localstorage liegt dann wird der VA im lfd. Betrieb die Festplatte angehaengt welche gesichert werden soll. Performance technisch ist dies viel besser als die Methode NBD welche "aussen" herum mit dem ESXi Hosts spricht und die Daten dann ueber das Netzwerk abfragt.

Die Daten werden dann komprimiert und optimiert (ABM) und werden dann von der VA direkt auf das Backup Ziel geschrieben.

Da man im optimum eine VA pro ESXi Hosts hat skalliert das auch entsprechend gut. Gleichzeitig kann die CPU Leistung des Hosts auch abgefordert werden weil die VA ja eine VM ist. Wenn man NBD verwenden dann hat VMware da wieder die Hand drauf und weist dort nur eine Geringe Anzahl an Resourcen zu.

Gruss
Joerg

[JayDe]

Ah, das macht sinn ...

Vielen Dank für die schnelle Hilfe

[JayDe]

Hallo Nochmal,
hier mal ein Auszug aus der Log von VRanger ... das Network Backup läuft aber HotADD will nicht...

[2012-07-18 16:10:27.894]: Local machine is a physical machine.
[2012-07-18 16:10:27.894]: Backup task will attempt to use VA-based VDDK HotAdd.
[2012-07-18 16:10:31.467]: The active map filter failed on vix:r:ddwcvvcs.adirdd.izfp-d.fhg.de:902:[eva-prod1] DDWADIR11/DDWADIR11.vmdk.
[2012-07-18 16:10:35.726]: Backup failed: An internal error occurred during execution, please contact Quest support if the error persists. Error Message: 3201 - can't open [eva-prod1] DDWADIR11/DDWADIR11.vmdk
[2012-07-18 16:10:35.726]: The failed backup task will be retried.
[2012-07-18 16:10:40.500]: Backup failed: An internal error occurred during execution, please contact Quest support if the error persists. Error Message: 3201 - can't open [eva-prod1] DDWADIR11/DDWADIR11.vmdk
[2012-07-18 16:10:40.500]: The failed backup task will be retried.
[2012-07-18 16:10:49.517]: Backup task using VA-based VDDK HotAdd failed: An internal error occurred during execution, please contact Quest support if the error persists. Error Message: 3201 - can't open [eva-prod1] DDWADIR11/DDWADIR11.vmdk
[2012-07-18 16:10:49.517]: Check the manual for compatibility issues when attempting Lan-free operations.
[2012-07-18 16:10:51.919]: Removing snapshot for vRanger completed.
[2012-07-18 16:10:52.496]: Backing up disk 'vix:r:ddwcvvcs.adirdd.izfp-d.fhg.de:902:[eva-prod1] DDWADIR11/DDWADIR11.vmdk:moref=vm-50:snapshot-2346:4' completed.
[2012-07-18 16:10:52.496]: An internal error occurred during execution, please contact Quest support if the error persists. Error Message: 3201 - can't open [eva-prod1] DDWADIR11/DDWADIR11.vmdk

Ich seher dass er da zur Appliance Connectet das funktioniert auch aber die VA kann die VDMK nicht mappen ...
Muss ich der VA einen Fibre Channel zugriff geben? dass Diese die Luns auf dem SAN sieht?

Danke und Gruß
Jürgen

[irix]

Nein die VAs haben und brauchen keinen Zugriff auf das SAN. Der ESX/vCenter haengt der VA die VMDKs an so das die VA "lokale" Daten sieht und einfach nur lesen muss.

Frage:
Ist zwischen vCenter und den VAs eine Firewall? Wenn ja dann Port 22 und 902 freigeben.


Ansonsten mal in der Solution KB bei Quest nach dem 3201 suchen. Da gibt es leider ein Dutzend Loesungen wenn diese Fehlermeldung Auftritt.

Gruss
Joerg

[Supi]

Aber so richtig bekommen die das zumindest beim ESXi 4.1 nicht hin:
5.5 neu installiert und trotzdem bei 2008R2 Server folgende FM:

Error Message: 3201 - can't open [LUN_3 RAID5] xxx.vmdk
[2012-07-19 09:00:04.648]: Backing up disk 'vix:r:srv01:902:[LUN_2 RAID5] xxxx-000003.vmdk:moref=vm-3109:snapshot-4622:2' completed.
[2012-07-19 09:00:08.969]: Backup failed: An internal error occurred during execution, please contact Quest support if the error persists. Error Message: 2800 - filter file contains the wrong number of blocks

[JayDe]

Hey,

also bei mir läufts jetzt ... ich depp hatte 1st und 2nd DNS server in der resolv.conf vertauscht ...
Umgestellt und schon ging es

Da muss man aber auch erst mal drauf kommen ...

Grüße
Jürgen

[Dayworker]

also bei mir läufts jetzt ... ich depp hatte 1st und 2nd DNS server in der resolv.conf vertauscht ...
Umgestellt und schon ging es

Da muss man aber auch erst mal drauf kommen ...

Die traurige Wahrheit bei Verbindungsproblemen unter ESX(i) oder vCenter ist aber gerade, daß in 95% aller Fälle "nur" fehlerhafte DNS-Einträge schuld sind.

[Supi]

Hey,

also bei mir läufts jetzt ... ich depp hatte 1st und 2nd DNS server in der resolv.conf

Dann Glückwunsch, bei mir leider immer noch nicht.

Eben noch mal getestet, der Job läuft sauber wenn ich die Option "Guest Quiescing" nicht aktiviert habe.
Schalte ich diese an, klappt es nicht mehr und es kommen die Meldungen:

Error Message: 2800 - filter file contains the wrong number of blocks
Error Message: 3201 - can't open LUN.

Dies aber erst seit 5.3. Und der Case ist auch schon seit Mai offen.