Hi,

wir habe hier eine paar alte Installationen mit Solstice DiskSuite. Plattenlayout mit root 4GB und var 6GB wird deutlich zu eng. Die root Platten mit 72GB werden durch 146GB Platten ersetzt. Dabei soll das Layout bzw die Größen der Filesysteme vergrößert werden.
Folgende Vorgehensweise ist geplant:

1. 2. Platte herauskonfigurieren.
2. 2. Platte tauschen
3. 2. Platte auf neues Layout slicen
4. 1. Platte auf 2. Platte spiegeln
5. Bootsektor auf 2. Platte
6. 1. Platte herauskonfigurieren.
7. 1. Platte tauschen
8. 1. Platte auf neues Layout slicen
9. 2. Platte auf 1. Platte spiegeln
10. Bootsektor auf 1. Platte
11. Filesysteme vergrößern
12. Reboot

Wobei folgende Befehle zum Einsatz kommen:

Alte Platten raus konfigurieren:

medadetach <mirror> <submirror>

metaclear <metadevice>

metadb -d <slice>

Neue Platte rein:

metadb -a -f -c 3 <slice>

metainit <contact/stripe> 1 1 <slice>

metattach <mirror> <metadevice>

Neue Platte bootbar machen:

installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk <raw-device>

Filesystem vergrößern (nachdem die zweite Platte auch getauscht ist)

growfs -M <mountpoint> <raw-devicw>

Schaun wir mal ob’s was wird

Haben wir mehrere Controler im System die die selbe Platte im SAN sehen können, benutzt VxVM per Default Multipathing im Balanced Mode.

Multipathing wird bei VxVM mit dem Befehl vxdmpadm administriert.

• list controller

vxdmpadm listctlr all

• list enclosures

vxdmpadm listenclosure all

• display Path

vxdmpadm getsubpaths ctlr=emc0

vxdmpadm getsubpaths dmpnodename=<enclosure>

• summing up

vxdmpadm getdmpnode enclosure=<enclosure>

• list I/O policy

vxdmpadm getattr enclosure <enclosure> iopolicy

• statistics

vxdmpadm iostat start

vxdmpadm iostart stop

vxdmpadm iostat show all

vxdmpadm iostat show all interval=5 count=10

vxdmpadm iostat show ctlr=<controler> | enclosure=<enclsure>

• performance

vxtrace -o dev,disk -g <diskgroup>

Hi,

man kann einem Mailserver auch “von Hand” eine Mail unterschieben. Ist zu Testzwecken manchmal nötig.

• per telnet auf Port 25 gehen

• helo <Empfänger Domain>
• mail from: test@senderdomain
• rcpt to: hugo@EmpfängerDomain
• data
• <bla bla bla>
• .
• quit

Vor ein paar Jahren hat mich mal ein Mailserver überrascht. Die Messages bei Sendmail waren alle von Hand getunt. Zum Abschied wurde ich gefragt: “was it as good for you as it was for me?”

So long

Hi,

Solaris vs Linux

Die Systemheroes schlagen zu!

Hi,

man braucht nur einen genügend großen Maschinenpark, dann kann man es öfter erleben:

Ein SUN gibt den Löffel ab (und alle andere Kisten mindestens genauso oft).

Ist eigentlich kein Problem, denn dafür hat man einen Wartungsvertrag. Ein Anruf, ein Rückruf und das zur Verfügung stellen eines “Exporers” und meist setzt sich der Techniker und die Ersatzteile auch schon in Bewegung. Die Teile werden getauscht, die Maschine noch mal per POST getestet und fertich is. Maschinen mit geschäftskritischen Anwendungen sollte es ohnehin zwei mal geben, also als Cluster. Als Ausfallzeit ist hier also nur die Umschaltzeit des Clusters zu verzeichnen.

Und dann gibt es die speziellen Fälle. Einen solchen durfte ich letztes Wochenende erleben.

Um es kurz zu machen: Auch diese Maschine hat SUN wieder hergestellt und es gibt keinen Grund zur Klage. Bis auf das Gehäuse und die Netzteile haben wir eine runderneuerte Maschine .

Das bedeutet aber auch: bare metal recovery

TSM ist das Backup/Restore System der Wahl dieses Kunden. Und das ist für Solaris mit Bordmitteln nicht fähig zu einem vollständigen Restore. Man benötigt also ein Bootmedium, eine RAM-Disk in die man dann den TSM Client installiert, das alte TSM Passwort oder auch ein Neues vom TSM Administrator und ….. ja genau – die Platten müssen so konfiguriert sein wie vorher. Und wie bitte war das? Tja, der Output eines alten Explorers währe nicht schlecht gewesen ….

Zwei Tage nach dem die Maschine wieder lief, laufen nun auch die wichtigsten Dienste wieder. Die Maschine läuft mit dem aktuellen Solaris Release (05/09), was insbesondere für die Zonen auf der Kiste ein erheblicher Fortschritt an Features für die Admins bringt . Und das Plattensubsystem wird mit ZFS verwaltet. Die alte Idee ca 40 Volumes mit SDS zu verwalten, war mir schon immer suspekt, aber dafür war es wohl ursprünglich auch gar nicht gedacht.

Fazit:

• regelmäßig per cron Explorer laufen lassen und Output auf anderer Maschine sichern
• nicht nur die Reaktionszeiten für die Hardware Instandsetzung für Ausfallzeiten kalkulieren, sondern vollständige Restore einplanen
• auch bei Entwicklungs und Testmaschinen kalkulieren was es kostet das auf die Maschine angewiesenes Personal rumsitzen zu lassen

In diesem Fall schätze ich mal, das eine zweite V490 auf die im Fehlerfall die ohnehin im SAN liegenden Zonefilesysteme umgezogen werden könnten, billiger gewesen währe …..