Cluster Filesystem in SunCluster
Diese Erläuterung von Tatjana Heuser ist zu gut, um sie in einem Kommentar verdorren zu lassen:
Das Cluster Filesystem war im Prinzip die innovativste Idee am SunCluster 3.
Die Intra-Cluster Kommunikation laeuft ueber einen Object Request Broker. Dieser laeuft - zumindest bis 3.1 - mit eingeschalteten Debug Flags. (Fuer die gerade freigegebene 3.2 Release noch nachsehen). Wenn man das abschaltet verliert man erweiterte Debug-Moeglichkeiten, gewinnt jedoch Durchsatz. Auch mit Traffic Shaping/Einstellungen fuer das private Network laesst auch noch eine ganze Menge herausholen, auch dieses nicht ohne Preis/Nebeneffekte. Das Cluster Filesystem ist ein Corba basierter Dienst, der eben auch ueber diese Intra-Cluster Kommunikation laeuft. Daher ist der Durchsatz im Clusterfilesystem leider auch durch die
Qualitaet/Geschwindigkeit des Sun Cluster private Networks bedingt. Wer also weiterhin nur 2x 100 MBit Interfaces im private Network faehrt, limitiert damit die Intra-Cluster Kommunikations Performance und implizit damit auch das Cluster Filesystem. HAStorage+ stellt im Prinzip eine Reinkarnation des einfachen Filesystem failover Mechanismus von Cluster 2.x dar. Dieser Mechanismus wird aus Performance Gruenden auch gerne im Sun Cluster 3.x verwendet. Wer also die Flexibilitaet des ClusterFS nicht braucht kann an der Stelle auf HAStorage+ zurueckgreifen. Wer hingegen die volle Flexibilitaet von Sun Cluster 3.x nutzen moechte, muss ins Backbone investieren. Ansonsten ist die Node, die den physikalischen I/O macht, auch die Node, die den Masterservice faehrt. Die Servernode hat den physikalischen Handle, die Proxynodes greifen ueber das private Network (ORB) auf das Proxy Filesystem zu.
Auf das im Kommentar auch noch erwähnte Buch zum Thema Sun Cluster 