DocData

Einfach das gesamte Design! Ich fasse zusammen: - ein physikalischer DC mit Eval-Lizenz (den kannst du eh platt machen, den bekommst du nicht mehr lizenziert, da es eine Eval UND ein DC ist) - einen lizenzierten virtuellen DC, den du aber nicht immer laufen lassen willst Kurz gesagt: Das funktioniert so nicht.

Keine Ursache. Hab ich doch total gerne gemacht.

Hä? Warum alles aktualisieren, wenn es vorher lief? Wie wäre ea mal sen Root Cause zu finden, bevor man wie wild installiert?? Wann hat das angefangen? Welche Änderungen an der Infrastruktur oder den Systemen gabe es vor dem Stichtag?

Sorry, aber unfassbar was DU ablieferst. Hauptsache die Schuld bei anderen suchen. Die 2 TB GPT/ MBR Problematik ist nicht neu. Beim RAID hättest du dich VORHER informieren können, welche Platten laufen. Statt den Restore immer wieder neu anzuwerfen, und dann auf Probleme zu stoßen, hättest du dich VORHER mit dem Verfahren auseinandersetzen können. Die Kundenmaschine steht zwei Monate bei dir. Der Kunde arbeitet mit einen Ersatzsystem, welches nicht alle Dienste anbietet. Also wenn ich der Kunde wäre, dann wäre das dein letzter Auftrag gewesen.

Wenn eure Anforderung der Betrieb von Anwendungen 24x7 ist, dann ist ein Cluster nicht das richtige Mittel um das zu erreichen. Beim Verschieben der Resourcengruppe hast du trotzdem eine Downtime. Ein virtualisiertes Cluster hat nur einen einzigen Vorteil: Es minimiert die RTO beim Ausfall der Betriebssysteminstallation. Dies gilt aber nur dann, wenn die im Cluster betriebene Anwendung keinen Schaden genommen hat. Ansonsten hat man trotzdem ein Problem und hoffentlich eine gute Recoverystrategie. Um auf deine konkrete Frage zu kommen: Bis auf ganz extrem wenige Ausnahme, würde ich alle Clusterdatenträger im VMFS anlegen und nicht als RDM durchreichen.

Den Overhead von RAID 6 spürst du, vor allem bei short Writes. RAID 6 istbwas für sequenzielle Workloads mit hohem Anteil an Read IO oder Archivdaten. Wenn das in eurem Fall passt... Ich würde heute keinem Kunden mehr ein Sytem empfehlen, was diese Form der traditionellen RAID Architekturen nutzt. Das ist, wenn überhaupt, noch etwas für sehr kleine Umgebungen außerhalb meines Kundensegments.

Redundanzen werden NICHT eingebaut um Wartungsarbeiten ohne Ankündigung und Wartungszeitraum durchzuführen.

Die Verkleinerung von Failure Domains erhöht die Zuverlässigkeit. Dieser Umstand ist unbestreitbar. Das ist aber auch der Grund warum ich Systeme, die noch tradiotionellen RAID Designs beruhen nicht mehr empfehle. Das betrifft z.B. DELL MD, EMC CLARiiON oder HP MSA. Offenbar wird hier auch gerne vergessen, dass die nutzbaren IOPS bei RAID 6 unter den Werten von RAID 5 liegen und man durch die höhere Write Penalty bei RAID 6 doppelt bestraft wird. Wenn man nur in sie eine Richtung optimiert, dann geht es auch nach hinten los. Zeit auf einen neuen Zug aufzuspringen. Vergesst die MD und investiert in ein entsprechend modernes System.

Nein, nicht wenn man es Richtig macht. In diesem Fall verwendet das Cluster andere Netzwerkanbindungen für den Heartbeat.

Es geht ja auch nicht um das Verschieben von Resourcengruppen, sondern um einen Failover. Behebe die Ursache, nicht das Symptom. Nein, kann nicht sein. Das ist ein Designfehler. Doch willst du. Behebe die Ursache, nicht das Symptom. Dir fehlt es offenbar an Redundanz im Netzwerk und an Verständnis für die Arbeitsweise eines Clusters. Das Cluster hat genau das gemacht, was es machen soll. Was du aber hast, ist ganz offenbar ein hässlicher Designfehler.

Es juckt den Cluster herzlich wenig das die Gastsysteme noch eine Netzwerkverbindung haben, wenn er netzwerkseitig isoliert wird. Insofern ist der Failover nachvollziehbar und by design. Korrekt wäre es gewesen die VMs vom Host zu evakuieren und DANN die Wartungsarbeiten durchzuführen.

Du sprichst in Rätseln und das nimmt einem die Lust dir zu helfen. Entschuldige meine offenen Worte, aber ich halte diese hemdsärmeligeArt "Wir machen das selber" für totalen Blödsinn. Das ist nicht effektiv, das ist nicht effizient. Selbst wenn ein Systemhaus anschließend prüft, macht es das nicht besser. Was versprecht ihr euch davon? Das ihr versteht und durchblickt was ihr da macht? Entschuldige bitte, aber dafür macht ihr das zu selten und dafür holst du dir hier gerade in zwei Threads zu viel Hilfe, als das man davon ausgehen könnte, dass du da wirklich weißt was du tust. Du sprichst in Rätseln, faselst was von Sicherheitskonzepten, das ihr alles selber macht, dir fehlt ganz offenbar eine Menge Wissen im Bereich Netzwerkgrundlagen etc. Du fummelst dir da was zurecht, am Ende räumt einer hinter dir auf und du hälst das für eine tolle Sache. Das ist der Moment wo ich bei (Neu)Kunden meine Sachen einpacke, den Kaffee austrinke, dem Kunden schönes Leben wünsche und mir beim Rausgehen noch einen Keks vom Tisch angel. Natürlich bitte ich den Kunden meine Kontaktdaten zu löschen. Du hast es nicht anders verdient. Ich bin raus aus dem Thread.

Wo liegt das Problem? Ich gehe mal davon aus du hast ProVision-basierte HP Networking Komponenten. Daher bleibe ich mal bei deren Terminologie von "tagged" und "untagged". Du legst die VLANs auf dem Switches an und denkst dir pro VLAN ein eigenes IP Netz aus. Die Ports an denen die Endgeräte hängen (z.B. Clients, Drucker, Kameras) werden auf "untagged" in dem jeweiligen VLAN gesetzt. Im Gegenzug werden die Uplinks in allen verwendeten VLANs auf "tagged" gesetzt. Die Uplinks landen mit hoher Wahrscheinlichkeit auf einem zentralen Switch. Dort werden die Ports "tagged" in allen VLANs gesetzt. Ich hoffe deine Firewall hat genug Interfaces. Jedes VLAN bekommt ein Interface auf der Firewall. Die Interfaces der Firewall werde an den zentralen Switch angeschlossen und die verwendeten Ports werden auf untagged in dem jeweiligen VLAN gesetzt. Dann verpasst du den Interfaces auf der Firewall eine IP Adresse. Diese IP Adresse kannst du als Gateway an den Endgeräten in dem jeweiligen VLAN verwenden. Nun kannst du auf der Firewall über Regel steuern welcher Verkehr zwischen den VLANs fließen darf. Wenn du weniger als 75% von dem Verstanden hast, was ich geschrieben habe, beauftrage jemanden mit der Konfiguration. Reiner Konfgurationsaufwand bei deiner Größe: Ca. 90 bis 120 Minuten. Wahrscheinlich eher weniger. Kindergeburtstag. Etwas für einen verregneten Sonntag. Wenn man sehr genau weiß was man tut, dann geht die Konfiguration im laufenden Betrieb.

VLANs haben mit der physikalischen Infrastruktur wenig zu tun und sollen dir dabei helfen eine logische Struktur über deine physikalische Netzwerkinfrastruktur zu legen. Die Art und Weise deiner Fragestellung verrät mir, dass es bei dir noch erheblichen Nachholbedarf in Sachen Netzwerkgrundlagen gibt. Um es ganz kurz zu machen: Das was dir vorschwebt geht. Mehrere VLANs übet eine Uplink und Terminierung der VLANs auf einer Firewall. Du sprichst von einem Sicherheitskonzept. Erste Frage: Wer hat das entworfen und warum wurde es erstellt? Grundsätzlich halte ich es für eine sehr gute Idee, wenn du dir externe Hilfe zur Umsetzung holst.

Die Einstellung von HP nimmt dir doch nicht das Nachdenken ab. Willst du jetzt HP dafür die Schuld geben? Du bist doch ein mündiger Administrator, insofern hättest du ja mal nachdenken können, statt Voreinstellungen einfach durchzuwinken. Gefahrlos muss das nicht sein. Wenn du ein Backup hast, dann kannst du das verkleinern. Geht es in die Hose (was passieren kann), dann hast du ja dein Backup.

CAPEX und OPEX sind dir Begriffe? Nimm den Beitrag von Robert und denk auch mal über Betriebskosten nach. Dann kannst du dir die Antwort selber geben.

Fileserver Cluster mit Witness in einer dritten Site. Entsprechende Speichersysteme dahinter, synchroner oder asynchroner Spiegel zwischen den Speichersystemen und eine Software, die bei einem Failover die gespiegelten Disks online bringt. Fertig ist die Laube. Alles andere wäre Flickwerk. Wenn ein Spiegel zwischen Speichersystemen gar nicht in Frage kommt, dann gerne etwas in Richtung HP StoreVirtual, NetApp Metrocluster oder DataCore SANsymphony-V, also alles Systeme, die man auf unterschiedliche Abschnitte verteilen kann und die einen nahtlosen Failover hinbekommen. Dann brauchst du nur noch ein Failover-Cluster über beide Räume verteilen.

Bitte prüfe die Netzwerkkarte. Mit der Konvertierung wird dein Exchange eine neue Netzwerkkarte bekommen haben (mit Standardeinstellung DHCP). Das gleiche passiert auch bei V2V Migrationen unter VMware, wenn sich die UUID der VM ändert.

Ja was denn nun? MS SQL oder MySQL?

Wie gut, dass das Buch von IBM gesponsort wurde, sonst würde wohl niemand mehr GPFS erwähnen. Aber danke für den Hinweis auf das eBook.

Diese Pauschale Aussage ist nicht richtig. Der Trend geht eher dahin auf Jumbo Frames zu verzichten. Wo es tatsächlich was bringt ist Live Migration/ vMotion. Im iSCSI Umfeld bringt es (heute) kaum noch etwas. Vor ein paar Tagen, auf der VMworld, gab es eine Session, in der das auch angeführt wurde (STO2496) In Zeiten von wire-speed Routing im Netzwerkkern muss man sowas nun wirklich nicht mehr machen. Aber um das mal ab Beispiel NetApp festzumachen: Da kann ich schon seit Jahren mehrere VLANs auf ein VIF legen und das Ding somit in mehrere Netze stellen, ohne irgendwie abgefahren routen zu müssen.

Das brauchst du mir nun wirklich nicht sagen. Aber die Art und Weise wie du argumentierst und was du schreibst lässt einen anderen Rückschluss zu. Dafür mache ich den Job schon zu lange und dafür habe ich zu viele Mandanten erlebt.

Und den Vendor Lock-In hast du bei einem SOFS nicht? Wahrscheinlich genausowenig, wie z.B. bei DataCore. :rolleyes:

Und weil die Anbieter alle gerne erzählen wie toll ihr Produkt ist (was würdest du in der gleichen Situation machen?), schraubst du dir selber was zusammen? Das Rad neu zu erfinden ist selten sinnvoll. Weder technisch, noch betriebswirtschaftlich. Du gehst ja auch nicht hin und rührst dir die Farbe zum streichen der Wände selber zusammen, nur weil Brillux erzählt wie toll ihre Farbe ist. Genausowenig baust du dir deine eigene Heizung, nur weil du Vaillant doof findest. Infrastruktur, egal ob Server, Netzwerk oder Storage, sind heute Commodities. Und deswegen sollte man da eigentlich keinen Hirnschmalz in die Entwicklung einer eigenen Lösung stecken. Wenn ich den SOFS betrachte und dann "Handling" und "Supportfähigkeit" als Kriterien heranziehe, dann fällt das Ding durch. Was erwartest du? Das du es selber supporten kannst? Das ist vielleicht dein Wunsch, aber wenn man nur Lösungen beschafft, die man wirklich selber versteht und supporten kann, dann bist du eigentlich nur noch mit der Lösungssuche beschäftigt und gehst nicht deinem eigenen Job nach. Was du machst ist mir nicht unbekannt. Ich habe einige Mandanten die genauso ticken. Einen hat das mal ziemlich in die sc***e geritten. Ich will dir den SOFS nicht madig machen. Aber die Position die du beziehst ("Premiumhersteller" bähh, selbst ist der Mann) ist für eine interne IT ziemlich grenzwertig.

Hallo, du schreibst: Ich halte das für brandgefährlich. Was sind ganz konkret deine Anforderungen? Übersichtlichkeit, also die Transparenz des Systems, ist gerade im Hinblick auf das Troubleshooting unverzichtbar. Irgendwie drängt sich mir der EIndruck auf, dass es auf jeden Fall ein SOFS werden soll, egal mit welchen Vor- oder Nachteilen.