PXE: DHCP-Optionen mit dem Swisscom VDSL-Router (Netopia 7347-84)

Der VDSL-Router Netopia 7347-84 kann so konfiguriert werden, dass PXE-Clients die richtige Adresse für den PXE-Bootvorgang erhalten:

Zuerst braucht es die DHCP-Option 60, welche PXE mal grundsätzlich aktiviert...

Netopia-7000/142244196416 (top)>> set dhcp gen-option name _dhcpc60

name "_dhcpc60"

option (60) [ 1 - 255 ]:

data-type (ascii) [ ascii | hex | dotted-decimal ]:

data (PXEClient) [ ascii ]: PXEClient

priority (low) [ low | high ]:

...dann mit der Option 66 die Adresse des TFP-Servers angeben...

Netopia-7000/142244196416 (top)>> set dhcp gen-option name _dhcpc66

name "_dhcpc66"

option (66) [ 1 - 255 ]:

data-type (ascii) [ ascii | hex | dotted-decimal ]:

data (192.168.1.10) [ ascii ]: 192.168.1.10

priority (low) [ low | high ]:

...und zu guter letzt den Dateinamen angeben, welche die Clients laden sollen:

Netopia-7000/142244196416 (top)>> set dhcp gen-option name _dhcpc67

name "_dhcpc67"

option (67) [ 1 - 255 ]:

data-type (ascii) [ ascii | hex | dotted-decimal ]:

data (/xbmc/pxelinux.0) [ ascii ]: /xbmc/pxelinux.0

priority (low) [ low | high ]:

OpenIndiana: pkgadd in der Zone

Bei der Erstellung einer Solaris-Zone wird in der Zone nur ein Minimum an Software installiert. Das zeigt sich beim Arbeiten in der Zone wie folgt:

root@sbs-dev:~# pkgadd -d http://download.blastwave.org/csw/pkgutil_i386.pkg
-bash: pkgadd: command not found

Damit mit man herausfindet, welches Paket auf dem System fehlt, kann mit folgendem Befehl gesucht werden:

root@sbs-dev:~# pkg search pkgadd
INDEX ACTION VALUE PACKAGE
basename file usr/sbin/pkgadd pkg:/package/svr4@0.5.11-0.148

Danach ganz einfach mittels PKG nachinstallieren:

root@sbs-dev:~# pkg install svr4
Packages to install: 3
Create boot environment: No
Services to restart: 1
DOWNLOAD PKGS FILES XFER (MB)
Completed 3/3 56/56 1.1/1.1$<3>

PHASE ACTIONS
Install Phase 138/138

PHASE ITEMS
Package State Update Phase 3/3
Image State Update Phase 2/2

Powershell-Einzeiler für Snapshotbereinigungen auf einer FAS

Folgendes Skript löscht alle Snapshots, welche älter sind als 30 Tage und auf einem Volume abgespeichert sind, welches die Zeichenfolge mxm beinhaltet.

get-navol | where {$_.Name -match 'mxm'} | foreach-object {$ParentName=$_.Name;get-nasnapshot $_.Name | add-member -membertype noteproperty -name ParentName -value $ParentName -passthru} | where {$_.AccessTimeDT -lt ((Get-Date).AddDays(-30))} | ForEach-Object {Remove-NaSnapshot $_.ParentName $_.Name -Verbose}

Folgendes Skript löscht Snapshots, bei welchen die Zeichenfolge clone im Namen vorkommt.

get-navol | foreach-object {$ParentName=$_.Name;get-nasnapshot $_.Name | add-member -membertype noteproperty -name ParentName -value $ParentName -passthru} | where {$_.Name -match 'clone'} | ForEach-Object {Remove-NaSnapshot $_.ParentName $_.Name -Verbose}

Wenn die Snapshots automatisch gelöscht werden sollen, so ist das Remove-NaSnapshot-CMDlet wie folgt zu vervollständigen:

get-navol | foreach-object {$ParentName=$_.Name;get-nasnapshot $_.Name | add-member -membertype noteproperty -name ParentName -value $ParentName -passthru} | where {$_.Name -match 'clone'} | ForEach-Object {Remove-NaSnapshot $_.ParentName $_.Name -Verbose -Confirm:$False}

Protection Manager: Verschieben eines SnapVault-Secondary Volumes

Planung hin oder her - es kann vorkommen, dass ein vom Protection Manager verwalteter Ressource-Pool volläuft und keine Möglichkeit besteht, diesen zu vergrössern.
Der Protection Manager bietet (mindestens in der Version 4) keine Boardmittel, um das Secondary-Volume in einen neues Aggregate zu verschieben.

Eine Rundum-Wohlfühl-Lösung habe ich keine gefunden, dafür aber eine Quick- und Dirty-Variante, bei welcher wenigstens keine Backups verloren gehen:

Step 1 - Daten auf das neue Volume spiegeln

vol create svdest_neu -l C.UTF-8 aggr1_sata 2340g
snap reserve svdest_neu 0
snap sched svdest_neu 0
vol restrict svdest_neu
snapmirror initialize -S svdest svdest_neu

Step 2 - Spiegel brechen

snapmirror update svdest_neu
snapmirror quiesce svdest_neu snapmirror break svdest_neu

Step 3 - Dataset bearbeiten
Als nächstes gilt es, das alte SnapVault-Secondary-Volume aus dem Dataset zu entfernen:


Step 4 - Volumes umbenennen / offline nehmen

vol rename svdest svdest_old
vol rename svdest_neu svdest
vol offline svdest_old

Step 5 - SnapVault-Beziehungen wiederherstellen

snapvault start -S 10.0.0.2:/vol/volume1/qtree1 /vol/svdest/qtree1
snapvault start -S 10.0.0.2:/vol/volume2/qtree1 /vol/svdest/qtree2
...
snapvault start -R /vol/svdest/qtree1
snapvault start -R /vol/svdest/qtree2
...

Step 6 - Dataset bearbeiten
Damit die Datensicherung wieder vom PM verwaltet wird, muss das neue Secondary Volume dem Dataset hinzugefügt werden.

Step 7 - Abschliessende Schritte
Altes Volume löschen, Guarantee auf None stellen, ...


Wichtig:
Die alten Backups werden nicht mehr von dem Protection Manager verwaltet und müssen deshalb manuell restored und schlussendlich auch gelöscht werden.

Volume gelöscht, obwohl LUN online & connected

Bei dutzenden Datenübernahmen ist es ziemlich schnell passiert, dass ein Volume auf dem NetApp-Filer gelöscht wird, ohne vorher das LUN auf dem Server zu disconnecten. Windows hat damit grosse Mühe, vorallem wenn das LUN nicht über einen Laufwerksbuchstaben, sondern über einen Volume-Mountpoint eingehängt war. Der Mountpoint ist ab diesem Moment "gelockt" und kann nicht wiederverwendet werden. Ein Reboot würde das Problem bestimmt beheben, je nach Produktivität des Server aber nicht wirklich möglich.

Für diesen Fall gibt es das Windows-interne Tool "mountvol".

Syntax wie folgt:

mountvol /D [mountpoint]

Ab sofort ist der Lock aufgehoben und der Mountpoint lässt sich wieder normal verwenden.

DFM: Report generieren via CLI

Belegte Kapazität der QTrees in einem Volume ausgeben:

dfm report view -F csv qtrees-capacity 7518 > qtrees.csv

Belegte Kapazität der Benutzer auf einem Volume ausgeben:

dfm report view -F csv -g 23723 users-quotas-total > userquotas.csv

SnapManager for SQL: Defaultpfade für neue DBs und Fulltext-Kataloge

Damit Datenbanken mit dem SnapManager für SQL von NetApp gesichert werden können, müssen diese natürlich auch auf NetApp-Storage liegen. Falls die interne Organisation eures Arbeitgebers den Betrieb der Datenbanken vom Betrieb des Backups trennt, kann dies ziemlich mühsam werden.
Kaum hat man das Backup eines SQL-Servers eingerichtet und die Datenbank auf das NetApp-LUN verschoben, so geht es nicht mehr lange bis der DBA eine neue DB oder einen Fulltext-Katalog auf der Systempartition (Non-NetApp-Storage) erstellt.

Zum Glück kann man die Standardpfade für DBs ziemlich einfach ändern:



Beim FullText-Katalog gehts leider nicht mit dem GUI, jedoch über die Registrierung. Unter folgendem Pfad

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.1\MSSQLServer

kann der folgende Schlüssel auf den gewünschten Pfad abgeändert werden:


Diese Konfiguration muss für jede Instanz durchgeführt werden.