Autor Archiv: danielbraun

Ich kenne nicht viele gute Gründe warum man eine Data Protector Installation von HP-UX auf ein anderes Betriebssystem wechseln sollte, dennoch gibt es viele Kunden die diesen Schritt gehen wollen und zum Beispiel auf Windows oder Linux wechseln; meist noch verbunden mit einem Upgrade auf eine aktuelle Version von Data Protector. Und hier genau steckt das Problem: es gibt keinen Migrationspfad. Der Grund hierfür ist ganz einfach, die DCBF Verzeichnisse zwischen UNIX und den anderen Betriebssystemen sind nicht kompatibel und somit gibt es keine Möglichkeit mit zum Beispiel einen Export und Import der internen Datenbank auf Linux zu wechseln. Die DCBF Verzeichnisse unter HP-UX sind im big-endian und auf Linux im little-endian Format abgelegt und hierfür gibt es kein Migrationstool. Was diese Formate kennzeichnet kann man bei einer Suchmaschine sehr schnell nachlesen.

Der Artikel ist recht umfangreich, es werden ca. 30 Minuten zum Durcharbeiten des Artikels benötigt, der Artikel richtet sich an Data Protector Experten. Am Ende des Artikels ist dann auch der Downloadlink für die verwendeten Export und Import Skripte.

Auf Grund der oben beschriebenen Problematik ist das einzige was man daher von einem HP-UX Cell Server migrieren kann das Verzeichnis /etc/opt/omni (die Backup Jobs, Schedules, …). Wie man trotzdem ganz leicht eine Migration vornehmen kann zeige ich nachfolgend am Beispiel HP-UX 11.11 – DP 6.11 nach Windows 2008 R2 – DP 6.2. Das Wesentliche was hierfür notwendig ist: das Importieren der Bänder in die neue Zelle. Ich habe durchaus schon Kunden gehabt die zwischen 500 und 2000 Bänder importieren mussten. Und erst mit dem Import der Bänder in die neue Zelle erhält man wieder die Historie (Restorefähigkeit) da bei dem Vorgang die DCBF Verzeichnisse wieder gefüllt und die Filename Versions wieder importiert werden. Diesen Schritt scheuen allerdings sehr viele Kunden da nur wenigen bekannt ist das man bei diesem Vorgang kein einziges Band in die Hand nehmen muss, es wurde mit Einführung von Data Protector 6.11 ein spezielles Kommando eingeführt der einen Export des Katalogs ermöglicht.

Im weiteren Verlauf des Artikels wird die Migration von HP-UX 11.11 auf Windows 2008 R2 und somit ein Migrationspfad aufgezeigt. Die durchzuführenden Schritte stellen nur einen von mehreren möglichen Varianten dar, im besonderen sind die Bedingungen am Ende des Artikels für eine erfolgreiche Migration zu beachten.

Folgende Schritte werden bei der Migration angewandt (es sind nur die wesentlichen Schritte dokumentiert):

1 Installation des neuen Cell Servers auf Windows 2008 R2

2 Library / Laufwerk:

2.1 physikalischer Umbau und Anschluss an den neuen Cell Server bei SCSI Library

2.2 Änderung des Zoning auf den neuen neuen Cell Server bei FC Library

3 Konfiguration des neuen Cell Servers:

3.1 global,

3.2 omnirc,

3.3 Hinzufügen weiterer DCBF Verzeichnisse, z.B.:

omnidbutil -add_dcdir "D:\ProgramData\OmniBack\db40\dcbf1" -seq 1

omnidbutil -add_dcdir "D:\ProgramData\OmniBack\db40\dcbf2" -seq 2

3.4 Hinzufügen von Filenames Extension Files, z.B.: (mehrmaliges Ausführen fügt mehrere Erweiterungen hinzu)

omnidbutil -extendfnames "D:\ProgramData\OmniBack\db40\datafiles\cdb" -maxsize 2047

3.5 weitere Optimierungen nach Bedarf (z.B.: Archiving – siehe Artikel zu obrindex.dat)

4 Deaktivieren des Schedules auf dem alten Cell Server mit dem Befehl /opt/omni/sbin/omnitrig -stop (das entfernt den crontab Eintrag)

5 Export der Clients aus der alten Zelle mit omnicc -export_host <Hostname>, wobei für Hostname der identische Name verwendet werden muss wie er auch im cell_info File steht. Zur Automatisierung kann man ein "cat" auf das cell_info File machen und über awk nur den Hostnamen ausgeben lassen und den Output in einem Shell Skript weiter verarbeiten. Aber nicht vergessen den Output zu sichern, die Hostnamen werden wieder für den Import benötigt. Beispiel für den Export:

MYHOSTS=$(cat /etc/opt/omni/config/server/cell/cell_info | awk '{print $2}')

for EXPORTHOST in ${MYHOSTS}

do

/opt/omni/bin/omnicc -export_host ${EXPORTHOST}

done

6 Falls noch weitere Installation Server zusätzlich zum Cell Server existieren und diese in der neuen Zelle benötigt werden so können die Server mit dem Befehl omnicc -export_is <hostname> auch exportiert werden (Outut sichern, damit die Server später wieder importiert werden können).

7 Import der Clients in die neue Zelle, die Hostnamen sind ja noch aus dem Export bekannt. Der verwendete Befehl für den Import ist omnicc -import_host <Hostname>, für den Import gelten die gleichen Angaben wie beim Export.

8 Import der zusätzlichen Installation Server in die neue Zelle mit dem Befehl omnicc -import_is <hostname>. Wenn der Installation Server auch aktualsiert werden muss, so erfolgt die Installation der Software auf dem Installation Server lokal und manuell. Achtung: Die Installation der Patches sollte nicht vergessen werden, sofern Patches verfügbar sind. Falls es in der neuen Zelle noch ein Installation Server für Linux/Unix benötigt wird, ein RedHat oder SLES (beides nur 64 Bit) ist unter VMware schnell installiert, die Installation des IS ist mit einem Aufruf schnell realisiert.

9 Upgrade der Clients auf die aktuelle Data Protector Version (Achtung: wer noch Windows 2000 Clients hat, belässt diese auf dem letzten Stand der Client Software da DP 6.2 kein Windows 2000 mehr unterstützt; diese Konfig ist supported für die Funktionen die in dieser Version enthalten sind. Es wird unter Umständen eine 6.11er GUI für den Import der Windows 2000 Clients benötigt.). Für die Aktualisierung oder Neuinstallation der Linux / Unix Clients muss unter Umständen noch der SSH Key auf dem Installation Server erstellt werden und auf die Clients verteilt werden.

10 Pools und Devices auf dem neuen Cell Server anlegen:

10.1 Hier können in kleinen Umgebungen die Libraries, Laufwerke und Pools neu angelegt werden. Diese Vorgehensweise bietet auch die Möglichkeit sich von „historisch gewachsenen“ Unmengen von Pools zu trennen, in der Regel reichen in mittelständischen Umgebungen maximal 10 Medienpools aus um alle Fälle abdecken zu können. Das gleiche gilt für die Laufwerke, hier möchte man vielleicht endlich von der Blocksize 64k auf einen höheren Wert von 256k oder auch 512k wechseln (abhängig vom Controller und den Laufwerken).

10.2 Löschen von nicht benötigten Pools, am einfachsten per Skript, es werden alle Pools außer "Default File" und "Default LTO-Ultrium" gelöscht:

omnimm -remove_pool "Default AIT"

omnimm -remove_pool "Default DDS"

omnimm -remove_pool "Default DLT"

omnimm -remove_pool "Default DTF"

omnimm -remove_pool "Default Exabyte"

omnimm -remove_pool "Default Optical"

omnimm -remove_pool "Default QIC"

omnimm -remove_pool "Default SAIT"

omnimm -remove_pool "Default SD-3"

omnimm -remove_pool "Default SuperDLT"

omnimm -remove_pool "Default T10000"

omnimm -remove_pool "Default T3480/T4890/T9490"

omnimm -remove_pool "Default T3590"

omnimm -remove_pool "Default T3592"

omnimm -remove_pool "Default T9840"

omnimm -remove_pool "Default T9940"

omnimm -remove_pool "Default Tape"

11 neue Pools per Skript anlegen, z.B.:

omnimm -create_free_pool "FreePool" "LTO-Ultrium" 60 250

omnimm -create_pool "Filesystem" "LTO-Ultrium" -free_pool "FreePool"

omnimm -create_pool "Database" "LTO-Ultrium" -free_pool "FreePool"

omnimm -create_pool "DataProtectorInternalDatabase" "LTO-Ultrium" -no_free_pool -no_move_free_media

12 Laufwerke und Libraries anlegen:

12.1 Hierfür kann man entweder die „Auto configure“ Funktion von Data Protector nutzen.

12.2 Das Tool sanconf, die Beschreibung steht im Client Reference Guide, funktioniert sehr zuverlässig.

12.3 Download der Libraries und Laufwerke mit dem Befehl omnidownload auf dem alten Cell Server, Bearbeiten der Dateien und Anpassung der Hostnamen, Übertragen der geänderten Dateien auf den neuen Cell Server, Anlage der Libraries und Laufwerke mit dem Befehl omniupload auf dem neuen Cell Server.

12.4 Eine weitere Alternative ist das Tool savedevices (findet ihr hier in www.data-protector.org), allerdings ist dies in der momentanten Version nur für Migrationen zwischen Windows einsetzbar, für Unix / Linux muss es noch angepasst werden.

12.5 die letzte Alternative wäre der Export der mmdb, der anschließende Import der mmdb und das abschließende Löschen aller Bänder in der neuen Zelle, da diese ja später erst durch die Skripte importiert werden. Im Abschluss muss noch der Cell Servername korrigiert werden, da beim Import die Laufwerke noch dem alten Cell Server „gehören“. Die Befehle hierfür wären zum Beispiel:

omnidbutil -writedb -mmdb /<ein Export Verzeichnis> – im Anschluss wird der Ordner auf den neuen Cell Server, z.B. nach c:\temp kopiert.

omnidbutil -readdb -mmdb c:\temp

omnidbutil -change_cell_name [<alter cell server>]

13 Selektives Kopieren der Inhalte aus dem alten /etc/opt/omni Verzeichnis auf den neuen Cell Server, hier macht es unter Windows Sinn mit dem Tool unix2dos die Dateien wegen der „anderen“ Zeilenumbrüche in das DOS Format zu übertragen. Wichtige Verzeichnisse sind hierbei in der Regel (kein Anspruch auf Vollständigkeit):

13.1 barlists

13.2 barschedules

13.3 datalists

13.4 schedules

13.5 copylists

13.6 consolidationlists

13.7 integ

Von der userlist im Users Verzeichnis sollten nur die Einträge übertragen werden welche die eigenen Benutzer darstellen. Die ersten 3-4 Zeilen auf dem neuen Cell Server wurden bei der Installation des Cell Servers angelegt, ein Überschreiben dieser Einträge kann den Zugriff auf den Cell Server verhindern.

Damit sind die vorbereitenden Arbeiten abgeschlossen und der neue Cell Server wäre nun auch schon einsatzbereit und fertig, jetzt müssen nur noch die Informationen von den alten Bändern und die Bänder in den neuen Cell Server importiert werden. Zu Beginn des Artikels habe ich schon erwähnt das für diesen Prozess kein einziges Band bewegt werden muss das es hierfür seit Data Protector 6.11 einen Befehl gibt. Die notwedigen Befehle habe ich in 2 Skripten zusammengefasst, einem exportcatalog.pl und einem importcatalog.pl Perl Skript; beide können nach Belieben angepasst und erweitert werden. Da für die Skripte bestimmte Bedingungen erfüllt sein müssen, verweise ich auch nochmals auf die genannten Bedingungen am Ende des Artikels. Beim Export des Katalogs auf dem Unix Cell Server werden die Dienste des Cell Servers nach jedem erfolgreichen Export eines Mediums neu gestartet. Der Grund ist hierfür der hohe Memory Verbrauch des RDS Daemons beim Export, der zum Crash des RDS Dienstes führen kann, wer das nicht braucht kommentiert es einfach aus. Zusätzlich habe ich in der .omnirc den _M_ARENA Parameter auf 1:32 gesetzt und in der rdmserver.ini die Threads auf 32 begrenzt. Sollte jemand auf gleiche Probleme stoßen und detailliertere Informationen zu den Einstellungen und Hintergründen benötigen, so kann ein Kommentar hinterlassen werden oder besser per Mail mit mir Kontakt aufgenommen werden.

Nun zu den Skripten:

Export:

1 Das Skript wird mit perl exportcatalog.pl aufgerufen, eine Installation von Perl ist nicht notwendig, die Module die durch Data Protector installiert werden sind ausreichend.

2 Das Skript auf Unix wurde mit Perl und Betriebssystemkommandos realisiert. Bei Bedarf (Spende) kann eine komplette Übersetzung auf Shell realisiert werden.

3 exportcatalog.pl:

# define the pools on source cell server
# all the pools must exist before starting the script
# it is recommended to move 100-200 pools to the transfer pool
# once all media are exported, continue with next 100-200 media

# in this pool we search for our media
my $pool="_TransferPool";


# on error we move the media to failed pool
my $errorpool="_TransferPoolError"; 


# once the media is exported it will be moved to a new pool
my $successpool="Z_MediaExported"; 


# define the paths we need during the export when no search path is set
my $omni_bin="/opt/omni/bin/";
my $omni_sbin="/opt/omni/sbin/";


# the directory to store the mcf files, a separate mount point was created for the migration
my $output="/exportcatalog"; 


# other stuff we need
my $command;
my @media;
my $media;
my $mediumid;
my $result;


# this will return the media ID - [XX1234L2] for all media in the transfer pool
$command=$omni_bin."omnimm -list_pool ".$pool." \| awk \'\{print \$2\}\'";
@media=`$command`;


# nextlines will do the export
foreach $media (@media)
{
  # next 3 lines to restart DP in case we have a memory problem with RDS (this makes the export faster)
  $command=$omni_sbin."omnisv -stop"; `$command`;
  $command=$omni_sbin."omnisv -start"; `$command`;
  $command=$omni_sbin."omnitrig -stop"; `$command`;

  chomp $media;
  # remove the brackets from the media ID - [XX1234L2] --> XX1234L2
  $media=~ s/\[//ig;
  $media=~ s/\]//ig;
  
  # we only run if we have a media
  if (($media ne "Medium") && ($media ne ""))
  {
    print "working on media: ".$media."\n";
    $command=$omni_bin."omnimm -copy_to_mcf ".$media." -output_directory ".$output." > ".$output."/".$media.".txt";
    `$command`;
    $command="cat ".$output."/".$media.".txt \| grep \'1 out of 1\'";
    $result=`$command`;
    if (!($result =~ /1 out of 1 catalog\(s\) successfully copied to file\(s\)./))
    {
      print "ERROR: export of media failed - moving to error pool\n\n";
      $command=$omni_bin."omnimm -move_medium ".$media." ".$errorpool;
      `$command`;
    }
    else
    {
      print "SUCCESS: media exported - moving to success pool\n";
      $command=$omni_bin."omnimm -move_medium ".$media." ".$successpool;
      `$command`;
      $command="cat ".$output."/".$media.".txt \| grep \' ('";
      $result=`$command`;
      ($dummy, $mediumid)=split(/\(/,$result,2);
      $mediumid=~ s/\)//ig;
      $mediumid=~ s/\.//ig;
      $mediumid=~ s/\:/_/ig;
      chomp $mediumid;
      print "renaming mcf file ".$mediumid.".mcf to done_".$mediumid.".mcf\n\n";
      $command="mv ".$output."/".$mediumid.".mcf ".$output."/done_".$mediumid.".mcf";
      `$command`;
      ### you may want to ftp the files afterwards to a different server when not picked up from the UNIX server
      $command="chmod 777 ".$output."/done_".$mediumid.".mcf";
      `$command`;
    }
  }
}

Import:

1 Das Skript wird mit perl importcatalog.pl aufgerufen, eine Installation von Perl ist nicht notwendig, die Module die durch Data Protector installiert werden sind ausreichend.

2 Für einen permanenten Import bereits exportierter Bänder wird empfohlen einen Scheduled Task auf dem neuen Cell Server mit dem Aufruf für die Dauer der Migration einzurichten.

3 Alle weiteren Dinge stehen als Kommentare im Skript.

4 importcatalog.pl:

# the same pool we used during the export, all media will be imported here
my $pool="_TransferPool";


# on the UNIX server a samba shared was used to export the catalog
# so we use the share to pickup the mcf files
# when samba cannot be configured you could enhance the exportcatalog.pl to upload
# the mcf files to another server using i.e. FTP
# my $source="Z:\\Migration\\exportedmedia\\";
# aternate source (line above) should be used when Samba is not used
my $source="\\\\unixserver\\exportcatalog\\";


# our working directory and the directory when the import is done
my $destination1="Z:\\Migration\\working\\";
my $destination2="Z:\\Migration\\done";


# other stuff we need
my $command;
my @media;
my $media;
my $mediumid;
my $result;


# we copy (no movement before import was successful) the mcf file to the working directory 
$command="copy ".$source."done*.mcf ".$destination1; `$command`;

# we build the array of files to be imported
$command="dir ".$destination1."done*.mcf /o/b"; @media=`$command`;


# next lines will do the work, on error the mcf file stays in the working directory until manually moved
foreach $media (@media)
{
  chomp $media;
  print "working on media: ".$media."\n";
  $command = "omnimm -import_from_mcf ".$destination1."".$media." -no_pool_prefix -orig_pool -import_as_original";
  $result=`$command`;
  if (!($result =~ /1 out of 1 media successfully imported./))
  {
    print "ERROR: import of media failed - renaming media\n";
    $command="ren ".$destination1."".$media." ERROR_".$media;
    `$command`;
  }
  else
  {
    print "SUCCESS: media imported - moving media to another location\n";
    $command="move ".$destination1."".$media." ".$destination2; `$command`;
    $command="del /q ".$source."".$media; `$command`;
  }
}

Der Export / Import der Bänder läuft mit den Skripten ganz automatisch ab, es ist kein Bänderwechsel oder ähnliches notwendig, die Migration läuft ganz nebenbei und benötigt nur wenig Kontrollarbeit. In gemischten Umgebungen mit bis zu 500 zu importierenden Bändern wird dieser Teil der Migration ca. 1 Woche laufen. Und hier noch der Downloadlink zu den Skripten:

[wpdm_file id=8]

Bedingungen:

1 Der alte Zell Server bleibt für die Migration und den Abschluss des Imports der Bänder bestehen.

2 Der Cell Server Name und die IP Adresse bleiben auf dem alten Cell Server erhalten (es wäre auch ein Wechsel möglich, dafür wären aber Emergency Lizenzen oder EVAL Lizenzen notwendig – bei Bedarf kann man seinen HP Partner, HP Partnerbertreuer oder HP VB anfragen).

3 Über Webware werden die Lizenzen auf die neue IP Adresse geändert.

4 Die Lizenzen werden auf dem neuen Cell Server erst eingetragen wenn der Export der Bänder auf dem alten Cell Server abgeschlossen wurde – solange verbleibt die neue Zelle mit den 60 Tage Instant On Lizenzen.

5 Nach Eintragung der Lizenzen auf dem neuen Cell Server muss der alte Cell Server deaktiviert werden da sonst eine Lizenzverletzung besteht.

6 Der alte Cell Server ist auf aktuellem Patchstand, nur dann ist ein Export der Bänder erfolgreich. Hintergrund: in den Patches vor Mai 2011 gab es ein Problem mit der Option „Log Files, Log Directories, Log Folder, Log All“ beim Exportieren und anschließendem Import der Bänder.

7 In der Datei global wird die Variable EnableMCFCompression=1 aktiviert. Die Variable wird für die Copy Catalog Session benötigt und komprimiert die geschriebene Katalogdatei.

8 Es steht ein ausreichend großes Migrationsverzeichnis zur Verfügung.

9 Die Bänder haben einen Barcode, falls es keinen Barcode gibt, so muss das Skript angepasst werden, damit die richtige Medium ID bestimmt werden kann.

10 Auf dem alten und neuen Cell Server muss perl vorhanden sein, ein einfacher Check mir perl -v prüft gibt die installierte Version zurück.

Diese Anleitung ist in dieser Ausführlichkeit nur bei www.data-protector.org zu finden, daher die Bitte an alle Consultants und Endkunden: wenn euch dieser Artikel geholfen hat und ihr in euren Projekten davon profitieren könnt, so würde ich mich daher über eine Spende (Donation Button rechts oben) freuen.