Todsünden bei der Journalisierung

24. Februar 2012 | Von | Kategorie: Hochverfügbarkeit

Die Versuchung lauert überall, und so gibt es auch Todsünden, zu denen sich manche Journal-Anwender verleiten lassen. Besonders schwerwiegend sind solche Sünden für Anwender, die mit Remote Journaling arbeiten. Oft vergrößert solches Fehlverhalten die Last, die Andere zu tragen haben, die sich rechtschaffen bemühen, eine effiziente Hochverfügbarkeitslösung zu erreichen. Nach einer kleinen Gewissenserforschung stellte ich die nachfolgende Liste zusammen: Wenn Sie auf dem Pfad der Tugend bleiben wollen, sollten Sie die Warnungen beherzigen, die Liste aufmerksam studieren und prüfen, wo Sie vom rechten Weg abweichen.

Fühlen Sie sich schuldig? Tun Sie Buße, lernen Sie, und optimieren Sie Performance und Zuverlässigkeit Ihrer Journalisierung

VON LARRY YOUNGREN

1. Sind Sie zu knauserig oder sogar richtig geizig?

Haben Sie Ihre Journalreceiver in einem separaten Speicherpool (ASP) isoliert und diesem Speicherpool dann nur eine Platteneinheit zugeteilt? Falls ja, ist Ihre Journal-Performance wahrscheinlich eingeschränkt, weil Sie sich benehmen wie Dagobert Duck. Sie sind dem Irrtum erlegen, dass etwas, das vor zehn Jahren Sinn machte, auch heute noch gut ist. Das ist es nicht! In den letzten zehn Jahren sind Plattenkapazität und Umdrehungsgeschwindigkeit gewachsen. Zuverlässigkeit und Schutzmechanismen haben sich enorm weiterentwickelt und, was am wichtigsten ist, sehr große Write-Caches im I/O-Adapter haben es weniger attraktiv gemacht, einen eigenen ASP für Journalreceiver einzurichten.

Eine einfache Faustregel, falls Sie darauf bestehen,einen eigenen ASP für Ihre Journalreceiver zu führen: Sorgen Sie dafür, dass der ASP nicht weniger als drei Platteneinheiten enthält. Bei jeder Anzahl unter drei fordern Sie Performance-Probleme heraus, weil Sie den Journalisierungs-Microcode daran hindern, die Fähigkeit zur Verwendung paralleler Plattenzugriffswege einzusetzen. Wenn Sie nicht dazu bereit sind, dem Journal- ASP mindestens drei Platteneinheiten zuzuweisen, sind Sie (zumindest hinsichtlich der Performance) besser beraten, die Journalreceiver wieder zurück in den System-ASP zu verlegen.

Mehr Informationen über die Vor- und Nachteile eigener ASPs für Journalreceiver fi nden Sie in der IBM Tech- Note Journaling – User ASPs Versus the System ASP. Mit dem Anwachsen der Plattenkapazitäten sind viele Anwender, die ursprünglich mehrere Platteneinheiten zu einem ASP konfi gurierten, dazu übergegangen, die Anzahl der Platten zu reduzieren. Wenn Sie dabei rückfällig geworden sind und eine ASP-Konfi guration mit nur einer Platteneinheit einsetzen, ist es an der Zeit, dass Sie sich bessern.

2. Konfigurieren Sie mehrere aktive Journalreceiver im selben ASP?

Falls das zutrifft, haben Sie auch dann eine Konfl iktsituation

Schlagworte: , , , , , , , , , , ,

Schreibe einen Kommentar

Sie müssen eingeloggt sein, um einen Kommentar schreiben.