Jump to content

dron

Members
  • Gesamte Inhalte

    11
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von dron

  1. Super - vielen Dank. Damit sollte das hinhauen.
  2. Hallo zusammen, ich habe eine Frage bzgl. WSUS Handling zu einem bestimmten Use-Case und wollte mal eure Meinungen dazu einholen. Wir nutzen einen dedizierten WSUS für eine spezielle Serverumgebung (QS und Prod), die einem monatlichen Releasemanagement mit einem vorgegebenen Test- und Freigabeprozess unterliegt. Die Windows Updates sind quasi ein Bestandteil eines Monatsreleases und werden mit einer automatischen Genehmigungsregel freigegeben. Die Updateinstallation wird scriptbasiert zu bestimmten Stichtagen getriggert. Der monatliche Ablauf sieht folgendermaßen aus: Rollout in QS-Umgebung Testing Monatsrelease Rollout in Produktionsumgebung nach 14 Tagen Leider kann es terminlich vorkommen, dass der MS-Patchday zwischen den beiden Installationterminen liegt. Dies führt zu abweichenden Patchständen zwischen den beiden Umgebungen. Gibt es eine elegante Möglichkeit eine automatische Genehmigung nur zu einem bestimmten Stichtag im Monat zuzulassen, bzw. durchzuführen? Wie würdet ihr das umsetzen? Bin für jeden Rat dankbar :) Besten Dank vorab & viele Grüße Björn
  3. Wie darf ich deine Frage verstehen? Würdest du FC bevorzugen?
  4. Vielen Dank für diese hochinteressanten Links. Diese helfen mir unwahrscheinlich weiter! Hab leider nur noch einige Verständnisfragen (geht nicht ganz aus den Artikeln hervor) und wollte mal dazu eure Erfahrungswerte einholen: 1) Thema MPIO: Wir planen als Storagelösung den Einsatz einer Fujitsu Eternus DX60. Diese verfügt über vier NICs auf zwei redundanten Controllern. Nach dem genannten BestPractise plane ich nun zwei iSCSI-Netzwerke. Genügt es aus Performancesicht im iSCSI Initiator MPIO zu aktivieren oder muss ich noch etwas berücksichtigen? Nur zur Rekapitulation: MPIO beinhaltet einen universellen DSM (voll funktionsfähig). Provider DSM sind nicht zwingend erforderlich, aber aus Optimierungssicht zu empfehlen, oder? 2) Thema CSV/Heartbeat und LiveMigration Netwerke: Meint ihr, dass eine Zusammenlegung auf eine NIC möglich wäre oder habt ihr diese Segmente komplett voneinander getrennt? Man muss dazusagen, dass die geplante Server-Umgebung doch recht überschaubar ist. Geht ihr hierbei über einen Switch oder über eine Direktverbindung auf die Server? 3) VM und Management Netzwerke: Habt ihr ein dediziertes Management Netzwerk oder aktiviert ihr dieses zusätzlich zur VM Kommunikation. Laut Best Practise sollte man trennen. Wie macht ihr das? Edit: Ich habe gerade gelesen, dass mit einer QoS-Anpassung dieses Konstrukt durchaus möglich wäre. Vermutlich ist das aber aus Performancegründen nicht zu empfehlen, da u.a. das Backup über diese NIC kommuniziert. Bedanke mich schon mal vorab!!! Viele Grüße Björn
  5. Hallo liebe Community, ich plane derzeit eine Hyper-V Umgebung mit zwei Hostsystemen (jew. 2 NICs für iSCSI), 2 Backend Switchen und einem zentralen Storagesystem (2 Controller mit jew. 2 NICs). Leider plagen mich noch Fragen zu der Netzwerkkonfiguration. Vielleicht kann mir jemand einen heissen Tipp liefern. Im Anhang findet ihr das Netzwerk-Design (Hinweis: es sind lediglich die NICs für die Storageanbindung geführt). Meine Fragen: 1) Wie gewährleiste ich in diesem Konstrukt eine hohe Performance (Link Aggregation). Erreiche ich das über MPIO oder muss ich auf Teaming/Trunks setzen? 2) Wie würdet ihr die IP-Adressierung vornehmen. Habe i-wo gelesen, dass man sämtliche Adressen in unterschiedliche Subnetze legen soll. Aufgrund der Kreuzverbindungen über die zwei Backend Switche bin ich mir hier aber nicht so sicher. Das Speichernetz soll laut unserer Planung außerhalb des Prod-Netzes liegen (ich denke, dass wird auch i.a.R. so gemacht). Auch wenn ihr meine Fragen als etwas trivial empfinden solltet, wäre ich für ein Feedback unwahrscheinlich dankbar. Ich helft mir mit jedem Post definitiv weiter. Besten Dank vorab & Viele Grüße Björn
  6. dron

    Bluescreen Hyper-V Host

    Nein, diese Seite war mir bis eben fremd. Wir konnten allerdings keinen passenden Eintrag finden.
  7. dron

    Bluescreen Hyper-V Host

    Hallo zusammen, wir haben folgende Umgebung: iSCSI SAN, 2xWS08R2 mit Hyper-V- und Failovercluster-Rolle. Als VM laufen 1 DC + 6 Memberserver. Das Hyper-V System lief ca. 4 Monate problemlos durch. Live-/Schnellmigrationen und Verschieben von VM's wurde zugenüge getestet. Zum Problem: Im laufenden Betrieb ohne sichtliche Systemeingriffe ist der 2. Hyper-Host gecrasht. Seitdem lassen sich folgende Dienste mit der Meldung Zugriff verweigert nicht mehr starten: Basisfiltermodul, DHCP-Client, NLA, Windows-Firewall, Diagnosrichtliniendienst. In der Eventlog konnten wir folgende Einträge ausmachen: Nachfolgend erscheinen noch weitere Fehler in den Eventlogs. Wir glauben aber, dass diese nur Folgefehler der eigentlichen Störung sind. Zwischenzeitlich haben wir den Node aus dem Failovercluster entfernt, die Hyper-V Rolle deinstalliert, den Server aus der Domäne genommen und anschließend den Server komplett neu installiert. Nachdem wir die Ausgangsbasis wieder hergestellt hatten, trat der o.g. Fehler nach ca. 4 Stunden erneut auf. Da ein weiterer DC als VM läuft, haben wir nachträglich die Zeitsync über die Integrationsdienste für diese Maschine deaktiviert. Die VM-Host und der virt. DC synchronisieren nun die Zeit über den phys. DC. Hat jemand einen heissen Tipp. Gerne stellen wir auch detaillierte Systeminformationen zur Verfügung. Viele Grüße Björn
  8. Hi Michel, danke, dass du dir die Zeit genommen hast auf diese tausend Fragen zu antworten :) Im Nachhinein wird einiges klarer. NIC-Teaming scheint doch elegantere Variante zu sein. Damit sind meine o.g. Fragen zu dem Netzwerkdesign wahrscheinlich hinfällig. Mich plagen aber immer noch zwei Verständnisfragen: 1) Angenommen ich setze diese drei Prod-LAN-NIC's als virtuelle NIC's ein. Was bewirkt denn das Sharing? Heisst das, das die zugehörige VM über diese NIC, also über das Gateway hinweg kommunizieren kann? Laufen dann die nicht-geshareten NIC's über die gemeinsame NIC in andere Netze? I-wie ist mir das noch nicht ganz so klar. 2) Was bedeutet denn im Failover-Manager ein Clusternetz, welches Clients den Zugriff erlaubt? Auf den virt. Maschinen kann ich ja das Failover-Netz für die Live-Migration definieren. Was machen dann die Clusternetze? Wahrscheinlich klingen die Fragen für euch sehr trivial. Allerdings komme ich trotz I-net Recherche (auch in eurem Forum) momentan nicht weiter. Besten Dank & viele Grüße Björn
  9. Hi Nils, dann werden wir wohl MPIO für das Gerät aktivieren. Komischerweise haben ohne MPIO null Probleme gehabt. Die Volumes konnten wir sauber anbinden... Die LUN's sind auch nur 1x erschienen. Kannst du uns evtl. auch bei den anderen Punkten 2-5 weiterhelfen???? Gruß Björn
  10. Vielen Dank für deine rasche Antwort. Nur zum besseren Verständnis: 1) IP-Adressen: verschrieben (100 --> 10) 2) Netzwerk-Redundanz Ok, das mit dem Teaming lassen wir dann mal sein :) D.h., dass wir im Falle eines NIC-Defektes nur den virt. Netzwerkadapter der VM manuell ändern müssten, oder? 3) Netzwerk Hyper-V Manager Es gibt ja im Hyper-V Netzwerk-Manager den Haken "Gemeinsames Verwenden dieses Netzwerkadapters für das Verwaltungsbetriebssystem". Muss diese Option bei allen 3 Produktiv-NICS gesetzt werden oder reicht es, wenn dieser Haken nur bei einem Adapter aktiviert wird? Was ist denn ratsam? Mir ist nicht ganz klar, was sich genau dahinter verbirgt. Wenn diese Option nicht gesetzt ist, dann erscheint kein virt Windowsadapter. 4) Netzwerk Failover Manager Im Failover-Manager werden ja die 4 o.g. Clusternetzwerke angezeigt. Der Konfigurationsassistent hat eine Warnung geworfen, dass mehrere Netzwerkkarten ins selbe Subnetz verweisen. Daher wird unter Clusternetzwerk_1 nur die Adapter virt_Switch01 und virt_Switch_12 angezeigt. Hat es einen bestimmten Grund warum nur diese beiden dargestellt werden? Was läuft denn überhaupt über das Clusternetzwerk, bei welchem die Option "Clients Verbindungen gestatten" aktiviert ist? 5) Produktivbetrieb Es handelt sich in unserem Fall um einen Prod-Betrieb. Ein virt. Server läuft noch zusätzlich als redundanter DC. 6) SAN Im iSCSI-Initiator habe ich lediglich die 4 SAN-IP's unter den Zielen eingetragen. Anschließend über Volumens habe ich die LUN's automatisch konfiguriert. MPIO ist nicht aktiviert. Benötige ich das zwingend? Besten Dank vorab & viele Grüße Björn
  11. Hallo zusammen, momentan bauen wir ein Hyper-V 2.0 Failover Netzwerk auf. Wir fragen uns, ob wir den richtigen Weg bzgl. des Netzwerkdesigns gewählt haben. Vielleicht kann uns jmd. einen kleinen Tipp liefern. Unsere Systeme sehen wie folgt aus: 2x Nodes Windows Server 2008 R2 (Hyper-V 2.0 und FailoverclusterManager) 1x DC Windows Server 2008 R2 1x SAN (iSCSI) Auf jedem Nodes sollen später 4 virt. Server gehostet werden. Jeder Nodes-Server verfügt insgesamt über 6 Netzwerkkarten. Wir haben folgende Aufteilung vorgesehen: 2x iSCSI, 1x Heartbeat / LiveMig, 3x ProduktivLan Somit haben wir jeweils im Hyper V Manager die 3 ProduktivLan-NIC's als extern definiert und den Haken für die gemeinsame Verwendung aktiviert. Bei den virtuellen Gastsystemen haben wir dann unterschiedliche virtuelle Netzwerke definiert. Dadurch wollten wir eine Lastverteilung erreichen. Daraus ergibt sich folgende Netzwerkkonfiguration: SAN: Crtl0Port0: 100.168.2.64 Crtl0Port1: 100.168.2.65 Crtl1Port0: 100.168.3.66 Crtl1Port1: 100.168.3.67 VM-Node-Server 1: Heartbeat (Cross): 100.168.1.20 iSCSI_1: 100.168.2.20 iSCSI_2: 100.168.3.20 LAN_1: virt_Switch_01 LAN_2: virt_Switch_02 LAN_3: virt_Switch_03 virt_Switch_01: 100.143.37.21 (SM: 255.255.255.0) (GW: .1) virt_Switch_02: 100.143.37.22 (SM: 255.255.255.0) (GW: .1) virt_Switch_03: 100.143.37.23 (SM: 255.255.255.0) (GW: .1) VM-Node-Server 2: Heartbeat (Cross): 100.168.1.21 iSCSI_1: 100.168.2.21 iSCSI_2: 100.168.3.21 LAN_1: virt_Switch_11 LAN_2: virt_Switch_12 LAN_3: virt_Switch_13 virt_Switch_11: 100.143.37.24 (255.255.255.0) (GW: .1) virt_Switch_12: 100.143.37.25 (255.255.255.0) (GW: .1) virt_Switch_13: 100.143.37.26 (255.255.255.0) (GW: .1) Das SAN wurde über den iSCSI-Initiator angebunden. Nach erfolgreicher Installation der virtuellen Gastsysteme haben wir dann den Failover Manager installiert. Nach der Konfiguration der CSV stehen uns nun 2 Knoten zur Verfügung. Unter den Netzwerken werden uns nun 4 Clusternetzwerke angezeigt: Clusternetzwerk_1: (Nodes_1 - virt_Switch01) / (Nodes_2 - virt_Switch12) aktiviert (Netzwerkkommunikation zulassen - Clients die Verbindung gestatten) Clusternetzwerk_2: (Nodes_1 - iSCSI-1) / (Nodes_2 - iSCSI-1) intern (Netzwerkkommunikation zulassen) Clusternetzwerk_3: (Nodes_1 - Heartbeat) / (Nodes_2 - Heartbeat) intern (Netzwerkkommunikation zulassen) Clusternetzwerk_4: (Nodes_1 - iSCSI-2) / (Nodes_2 - ISCSI-2) intern (Netzwerkkommunikation zulassen) Nun stellen sich uns doch einige Fragen: Ist die Aufteilung der Netzwerkkarten sinnvoll, bzw. ist die Konfiguration soweit in Ordnung? Ist in dieser Konstellation eine Lastverteilung und ein Failover bei einem NIC-Ausfall gegeben? Jedenfalls bedanke ich mich schon mal vorab und wünsche euch ein schönes Weihnachtsfest. Viele Grüße Björn
×
×
  • Neu erstellen...