amsfas21> df -s
Filesystem                used      saved       %saved
/vol/vmware_data01/   68863864  303083528          81%

Da bin ich doch baff. Mal sehen. Hab schon ca. 20 VMs auf den neuen FAS2020 migriert. Mal sehen wie es aussieht wenn ich alle Server drüben hab.

ifconfig vifname alias ip-address

also

ifconfig vif0 alias 192.168.5.100 netmaks 255.255.255.0

Nicht vergessen darf man, diese Zeile auch in die rc Konfigurationdatei auf dem File einzutragen, damit die Änderung auch einen Reboot übersteht.

options telnet.enable off

Telnet deaktivieren.

Filer A (FAS250) ist langsam voll. 1 Volume muss auf einen anderen Filer verschoben werden

Lösung:

Snapmirror! Ganz einfach.

Auf Filer A muss ich Filer B zuerst für Snapmirror “berechtigen”

options snapmirror.access host=filerB

Dann erstelle ich auf Filer B das Volume

vol create data1 aggr0 250g

Das Volume stelle ich dann auf restricted

vol restrict data1

Dann starte ich den Snapmirror (immer noch auf filerB)

snapmirror initialize -S filerA:data1 filerB:data1

Ich erstelle keinen Schedule, da ich die Daten ja nur einmal rüberkopieren muss (ok, zweimal für den Sync am Schluss)

Überwachen kann ich den Snapmirror status mit

snapmirror status

Snapmirror is on.
Source                Destination           State          Lag        Status
filerA:data1        filerB:data1        Uninitialized  -          Transferring  (32 GB done)

Dann einfach warten bis initial Snapmirror durch ist. Während dieser Zeit ist das Volume auf dem Source Filer natürlich online und kann weiterhin gebraucht werden. Nach dem der inital Snapmirror durch ist stelle ich sicher, dass auf dem Volume nicht mehr gearbeitet wird. Z.b. in dem ich den CIFS Share entferne oder die iSCSI Sessions terminiere. In meinem Falle ist es ein CIFS Share, der entfernt wird. Danach mache ich ein letztes Update mit (auf filerB):

snapmirror update -S filerA:data1 filerB:data1

Danach kann ich das Ursprungsvolume auf filerA offline setzen:

vol offline data1

Dann den snapmirror “brechen” (auf filerB):

snapmirror break data1

Da ich den Snapmirror nicht mehr mit dem ursprünglichen Volume resyncen will (das werde ich nahher löschen) und ich vielleicht das Volume in Zukunft vergrössern will setze ich das fs_size_fixed Flag auf off (filerB):

vol options data1 fs_size_fixed off

Nun muss ich nur noch eventuelle CIFS shares, NFS exports oder iSCSI targets neu erstellen. Das alte Volume kann ich dann löschen.

Falls das Volume sehr gross ist und ein initial mirror sehr lange geht (z.B. mehrere Stunden oder Tage), dann kann man natürlich vor dem letzten Update noch mehrere snapmirror updates fahren, während das ursprüngliche Volume immer noch weiterläuft. Dadurch wird der Lag (d.h. der Zeitliche Abstand, um den der Mirror dem Original hinterher hinkt) immer kleiner, so dass ein letzter snapmirror update am Schluss nur noch Sekunden oder ein paar Minuten dauert, anstelle von Stunden.

dfm host diag filerA.local

C:\>dfm host diag filerA.local

Network Connectivity
IP Address             192.168.0.100
Network                None
DNS Aliases            filerA.local
DNS Addresses          192.168.0.100
SNMP Version in Use    SNMPv1
SNMPv1                 Failed: Timeout (Unknown error)
SNMP Community         public

eingeben (anstelle von filerA.local natürlich euren Hostnamen für den Filer). Dann sieht man sofort was nicht geht. Meistens ist der Zugriff via SNMP nicht möglich, weil z.B. SNMP nicht aktiviert ist. Das kann man auf dem Filer folgendermassen prüfen:

filerA> options snmp
snmp.access                  legacy
snmp.enable                  off

Hier sieht man, dass snmp nicht aktiv ist.

filerA> options snmp.enable on

Dies aktiviert snmp, was man auch überprüfen kann

filerA> options snmp
snmp.access                  legacy
snmp.enable                  on

Nun sollte ein hinzufügen klappen.

secureadmin setup ssh

Nach dem Start des “Wizards”  fragt er nach der Key size. Danach erzeugt der die Keys und startet den SSH Dienst. Das war’s auch schon.

SSH Setup
———
Determining if SSH Setup has already been done before…no

SSH server supports both ssh1.x and ssh2.0 protocols.

SSH server needs two RSA keys to support ssh1.x protocol. The host key is
generated and saved to file /etc/sshd/ssh_host_key during setup. The server
key is re-generated every hour when SSH server is running.

SSH server needs a RSA host key and a DSA host key to support ssh2.0 protocol.
The host keys are generated and saved to /etc/sshd/ssh_host_rsa_key and
/etc/sshd/ssh_host_dsa_key files respectively during setup.

SSH Setup will now ask you for the sizes of the host and server keys.
For ssh1.0 protocol, key sizes must be between 384 and 2048 bits.
For ssh2.0 protocol, key sizes must be between 768 and 2048 bits.
The size of the host and server keys must differ by at least 128 bits.

Please enter the size of host key for ssh1.x protocol [768] :
Please enter the size of server key for ssh1.x protocol [512] :
Please enter the size of host keys for ssh2.0 protocol [768] :

You have specified these parameters:
host key size = 768 bits
server key size = 512 bits
host key size for ssh2.0 protocol = 768 bits
Is this correct? [yes]

Setup will now generate the host keys. It will take a minute.
After Setup is finished the SSH server will start automatically.

amsfas21> Thu Jun 25 13:46:49 GMT [secureadmin.ssh.setup.success:info]: SSH setup is done and ssh2 should be enabled. Host keys are stored in /etc/sshd/ssh_host_key, /etc/sshd/ssh_host_rsa_key, and /etc/sshd/ssh_host_dsa_key.

Nach der Installation muss nur noch ein Konfigurationfile erstellt werden. Ein einfaches Konfigurationsfile sieht folgendermassen aus:

backup
vcip=VCHost
vcuser=vibe
vcpasswd=secret
sauser=vibe
sapasswd=supersecret
dsset=vmware_volume:172.30.129.100
verbose

Hier mache ich ein Backup, vcip ist die IP oder Hostname des Virtual Centers. Danach folgen der Virtual Center User und sein Passwort. sauser ist der Username der für den Login auf dem Netapp Filer verwendet werden. sapasswort sein Passwort. Mittels dsset sage ich VIBE, dass es von allen VMs, die mind. eine Disk auf dem vmware_volume (NetApp Volume) haben einen VMWare Snapshot macht, danach einen NetApp Snapshot des Volumes. Am Schluss werden die VMWare Snapshots wieder entfernt. Wenn wir dies in ein Textfile vibe-backup.cfg speichern können wir mit

vibe --config vibe-backup.cfg

den Backup Prozess starten. Falls das Volume noch gemirrored wird, können wir dies mit:

vibe --config vibe-backup.cfg --updatemir --miruser remoteuser --mirpasswd supersecret

machen. Dann wird nach dem Snapshot der Snapmirror vorgang auch noch mitgestartet.

Zuerst schalten wir NDMP mit ndmpd on ein. Danach können wir mit ndmpd status sehen, dass NDMP auch wirklich läuft:

Nun stellen wir noch ein, dass wir mittels Username und Passwort auf NDMP zugreifen wollen:

Wir müssen sicherstellen, dass NDMP Version 4 verwendet wird:

Falls dies noch nicht der Fall ist können wir dies explizit setzen:

Nun können wir den Filer als NDMP Host hinzufügen. Dazu gehen wir in der BackupExec Konsole auf Tools -> Device and Media Operations -> Add NDMP Server

Im neu erscheinenden Fenster geben wir den Hostname oder IP des NetApp Filers an und den Account mit dem BackupExec sich verbinden soll:

Das war’s auch schon. Nun können wir bei Backups oder Backup Selection Lists den NetApp Filer auswählen und Volumes, Qtrees oder einzelne Files sichern:

Ich hatte das Problem, dass ich bei einem R200er Filer einen neuen NFS Eintrag ins exports file geschrieben habe. Das ganze von einem Windows Client aus, c$\etc\exports geholt und mit einem vernünftigen Editor (so von wegen Unix <-> Windows mode), sprich Notepad++, den Eintrag eingefügt, gespeichert und auf dem Filer

exportfs -a

ausgeführt. Der NFS export wurde aber nicht angezeigt. Nach einer Weile hab ich dann das Problem gefunden:

Am Schluss der letzten Zeile muss unbedigt eine neue Zeile (LF) eingefügt werden, sonst wird der letzte Eintrag ignoriert.

Steht sicherlich irgendwo in der Dokumentation. Wusst ich jetzt aber nicht mehr und hat mich 1h gekostet.