Zukunftssicher?

Bei iSCSI handelt es sich um eine ausgereifte, unternehmensfähige Technologie. Sie wird vom ganzen Markt getragen, es existieren entsprechend optimierte Netzwerkkarten und -switche sowie professionelle Storage-Lösungen und Software für Linux und Windows. Damit steht iSCSI auf einer Stufe mit Fibre Channel und NAS. Das spiegelt sich auch in der Fülle der unterstützten Features.

Problem mit Raid

Vieles spricht dafür, das oben geschilderte Szenario nur für Testsysteme und Experimente zu nutzen und sich ansonsten einen professionellen iSCSI-Storage anzuschaffen. So ist Software-Raid über iSCSI-Devices meist problematisch [8] , der Administrator handelt sich zudem viel Arbeit ein, wenn einmal im unternehmensweiten Einsatz die Forderung nach Persistent Reservations aufkommt. Die braucht er fürs Windows-Server- Failover-Clustering, Iscsitarget unterstützt sie aber nicht [9] .

Im schlimmsten Fall muss er mit der Einrichtung neu beginnen, allerdings wohl mit einer Target-Software, für die es keinen derart simplen Konfigurator wie Yast 2 gibt. Erfahrungsgemäß beheben die Hersteller professioneller Storage-Produkte solche Probleme schnell und es ist fast immer einfacher, ein Firmware-Update einzuspielen, als sich mit kniffligen Problemen dieser Art auseinanderzusetzen.

Für den Unternehmenseinsatz ebenfalls wichtig ist Boot from SAN (iSCSI Boot Firmwar Table (IBFT), http://10 ), da sich damit eine Provisioning-Infrastruktur einrichten lässt. Ob sich ein Computer in die SAP-Landschaft integriert oder als Webserver zum Einsatz kommt, entscheidet dann das Bootimage, das der Admin ihm zur Verfügung stellt. Eine weitere Voraussetzung ist die Fähigkeit zu Snapshots, die eine Downtime für die Datensicherung unnötig macht. Das System arbeitet weiter, während der Admin in aller Ruhe vom Snapshot ein Backup anfertigt. Auch dafür steht in Yast ein eigener Reiter parat ( Abbildung 3 ).

Ein weiteres Unternehmens-Feature, das professionelle iSCSI-Storages bieten, ist die Authentisierung von Nutzern mittels ihrer IP-Adressen, Initiator-Namen oder mit Chap-Authentisierung. Falsch ist dagegen die verbreitete Einschätzung, dass Cluster unbedingt Blockdevices verlangen. Beispielsweise arbeitet Oracles Real Application Cluster auch mit NFS-Storages zusammen. Mit NFS verschiebt sich sogar das Problem des File Locking elegant an eine zentrale Stelle. Falls hier OCFS2 mit Block-basierten Devices zum Einsatz kommt, müssen die Clusterknoten das File Locking über das Netzwerk untereinander ausmachen.