DocInfra

Ich habe kein Wort verstanden. Wieviele Netzwerkkarten hast du pro Server? Zwei Karten? Und du möchtest diese beiden Server mit zwei Kabeln direkt verbinden um darüber iSCSI zu nutzen? Einer als Target und einer als Initiator? Oder wie stellst du dir das vor? Beide Karten sollen als Team agieren, und wenn eine ausfällt, soll die andere übernehmen? Sollen bis zum Ausfall beide parallel arbeiten?

Lass bitte mal netdiag und dcdiag durchlaufen. Beide Tools sind in den Windows Server 2003 Support-Tools enthalten.

Die Raptor nutzt nun mal die gleichen mechanischen Komponenten wie bei den SCSI Platten. Sonst würde das Ding, wie oben schon gesagt, bei 15k UPM auseinanderfliegen. Und sowas kostet nun mal Geld.

Ich kenne GFS nicht im Detail, aber so sieht es wohl aus. Der parallele Zugriff auf blockbasierten Speicher ist immer ein Problem. Genau für sowas gibt es spezielle Dateisysteme, wie GFS oder OCFS2, oder aber den filebasierten Zugriff per SMB/CIFS, (open)AFS oder NFS.

Paralleler Zugriff mit mehreren Servern ist nur bei entsprechendem Dateisystem möglich. Unter anderem Oracle Cluster Filesystem oder GFS. Mit Veritas Filesystem, ReiserFS, NTFS, ext2/3 usw. ist das _nicht_ möglich. Dann musst du die Platte an einen Server anbinden und die Daten per Windows Freigabe oder NFS o.ä. bereitstellen.

Der Begriff ist geläufiger.

Manchmal ist damit auch die Art und Weise gemeint wie eine Datenbank die Daten speichert. So gibt es verschiedene Backends für MySQL, z.B. InnoDB oder BerkeleyDB.

Ich kann das gleiche von Bechtle berichten, aber von mehreren verschiedenen Standorten. Der Standort Stuttgart ist mir auch bekannt. Ein Kunde von uns hat bei denen mal eine größere Geschichte abgewickelt und war extrem unzufrieden mit denen.

Kurze Suche in der Microsoft Knowledgebase hätte gereicht: Uptime.exe Tool Allows You to Estimate Server Availability with Windows NT 4.0 SP4 or Higher

Also diese Einstellung hat dein Problem definitiv nicht gelöst, da sie totaler Quatsch ist. Ein ipconfig /registerdns auf dem ersten DC hätte dein Problem zu 99,9% gelöst.

Klemm doch einfach mal einen Rechner mit einem Packetsniffer zwischen den COM Server und den Switch. Einfach einen alten 5 Port HUB dazwischen und Switch, Rechner und COM Server dort anschließen. Dann Wireshark auf dem Rechner installieren und den Verkehr zwischen COM Server und deinem dem Server / Rechner, auf dem deine JAVA Applikation läuft, mitschneiden und analysieren. Das Blinken der RX und TX Leuchten ist kein wirklich brauchbarer Indikator. Die blinken nämlich auch, wenn der COM Server ARP Anfragen empfängt beantwortet, Brodcasts dort ankommen uns.

*hüstel* Link

Sicherlich auch interessant: Sein Thread hier.

Kann ich nur bestätigen. Bei einem Windows 2003 Standalone Server (kein DC) muss man auch keine GPO anpassen um die lokale Anmeldung zu erlauben, dafür gibt es eine lokale Gruppe der Remotedesktopbenutzer.

Erstmal ein dickes "HÄ?!". Dieser SSL312 sieht für mich schwer nach einer SSL-VPN Appliance aus, vergleichbar mit Avantails SSL-VPN Appliance oder den Teilen von Juniper. Du bist dir aber ganz sicher das du die Kiste auch korrekt konfiguriert hast. Mit welchem Protokoll willst du denn auf den NT Server zugreifen?

Brauchst du nicht und hat auch nichts damit zu tun. Die Treiber für gängige HBAs sind im Kernel drin, oft bieten Hersteller Sourcen der Treiber an. Ob Emulex, QLogic, Atto, Vixel o.ä. is egal. Ich habe bessere Erfahrungen mit QLogic gemacht, Emulex war früher mal mehr verbreitet. Ist aber auch egal. Ein FL-Port ist übrigens ein Fabric-Loop Port. Daran können also dann auch FC-AL Devices an eine Fabric angeschlossen werden. Darauf musst du achten.

Der HBA muss FC-AL unterstützen. Die GBICs sollten passend sein, sollten halt keine Longwave GBICs sein. Sind bei HBAs auch eher ungewöhnlich. Die 2 GBit sind abwärtskompatibel, 1 GBit FC funktioniert also auch. Automatisch passiert da gar nichts. Du musst schon die LUNs auf dem Array einrichten und dann an den Host präsentieren. Dann hast du aber ein "normales" SCSI Device am Host mit dem du arbeiten kannst.

Der gute, alte Software-Mirror über Veritas... Die T3 kann schon RAID und die größeren Storage von SUN sind eh von HDS. Das is dann auch richtige "Männertechnik". Die T3 ist zwar nicht mit Linux zertifiziert, aber FC-AL, HBA und SCSI ist auch kein Hexenwerk. Sehe keinen Grund warum das nicht laufen sollte.

Meinst du die T3? Die T3 ist kein JBOD, die kann schon RAID 0, 1 und 5. Administriert wird das Ding über den Sun StorEdge Component Manager.

Das Storage spricht normales SCSI, allerdings kommt als Transportprotokoll Fibre-Channel zum Einsatz. SCSI ist bei FC ein ULP (Upper Layer Protocol), weitere ULPs sind z.B. FICON oder HIPPI. Du brauchst in deinem Server einen sog. Fibre-Channel HBA (Host-Bus Adapter). Das Gerät kannst du entweder direkt anschließen (Point-2-Point), über einen FC-Hub (FC-Arbitrated Loop) oder mittels FC-Switch (Fabric). Anschließend erscheinen die logischen Laufwerke auf dem Storage an deinem Host als normale SCSI Devices. Diese logischen Laufwerke nennt man auch LUNs.

Dann beschäftige dich mal mehr mit solchen "Appliances". Zur Info: Auf der Watchguard läuft auch nicht mehr als ein Linux. Eine Netscreen von Juniper kann da schon mehr als ein Linux mit ein bisschen IPtables.

Na wer wird denn gleich ausfallend werden? Locker bleiben, Schock bekämpfen. Du hast scheinbar nicht verstanden was ich sagen wollte, daher sage ich es dir in meiner ach so freundlichen Art noch mal ganz deutlich: Wo Enterprise anfängt und wo es aufhört, kommt auf den Standpunkt des Betrachters an.

Und wo ist der Schalter /PAE?

Und wo liegt dann das Problem das mit Windows Server 2003 abzudecken?? Nein. Novel SUSE Linux Enterprise Server oder RedHat Enterprise Linux, jeweils in der aktuellen Version und passendem Maintenance Paket.

Ist bei uns auch so. Mindestens Abitur oder Fachhochschulreife.