23
Raid5 Performance - Cache Aktivierung - 4x900GB SAS 10k rpm
Hallo zusammen,
ich bin seit ein paar Jahren fleißiger "Mitleser" und erfreue mich oft an guten und fundierten Beiträgen hier im Forum. Also nun offiziell "Hallo zusammen!"...
Nun habe ich jedoch ein Problem, welches ich nicht zu lösen vermag und auch über die Suche zu keinem eindeutigen oder befriedigendem Ergebnis gelange.
Wir haben ein System welches mit starken Performance Problemen zu kämpfen hat.
WS2012 (mit Hyper-V und DC konfiguriert)
2xE5-2630 (12C/24T)
64GB RAM
LSI-MR9271-8i Controller
4x900GB SAS 10k rpm (als Raid5 mit 3 Platten + Spare)
VM's:
- TerminalServer (4C, 32GB RAM)
- SQL Datenbank (4C, 16GB RAM)
- Entwicklungsumgebung für WaWi-System (2C, 2GB RAM)
Nach einigen Tests mussten wir mit Schrecken feststellen, welche Performance das System liefert. Nicht nur das ein Vorgang aus dem WaWi-System auf einem Laptop doppelt so schnell abläuft, auch der Zugriff direkt am Host scheint seine "Laggs" zu haben. Diese sind zwar nur minimal, aber sie sind vorhanden.
Auszug aus einem HDD_Bench mit CrystalDiskMark:
Sequential Read : 3373.574 MB/s
Sequential Write : 38.039 MB/s
Random Read 512KB : 2627.551 MB/s
Random Write 512KB : 32.909 MB/s
Random Read 4KB (QD=1) : 32.877 MB/s [ 8026.6 IOPS]
Random Write 4KB (QD=1) : 0.731 MB/s [ 178.6 IOPS]
Random Read 4KB (QD=32) : 259.857 MB/s [ 63441.7 IOPS]
Random Write 4KB (QD=32) : 3.067 MB/s [ 748.8 IOPS]
Nun meine Frage, da ich dazu wie gesagt nicht viel eindeutiges gefunden habe:
- Festplattencache ist deaktiviert --> Kann dieser aktiviert werden? Zusätzlich zu dem Raid-Controller-Cache?
- Ist das Raid5 überhaupt die richtige Konfiguration?
- Würde ein SSD-Cache-Controller etwas bringen?
Danke für eure Hilfe!
ich bin seit ein paar Jahren fleißiger "Mitleser" und erfreue mich oft an guten und fundierten Beiträgen hier im Forum. Also nun offiziell "Hallo zusammen!"...
Nun habe ich jedoch ein Problem, welches ich nicht zu lösen vermag und auch über die Suche zu keinem eindeutigen oder befriedigendem Ergebnis gelange.
Wir haben ein System welches mit starken Performance Problemen zu kämpfen hat.
WS2012 (mit Hyper-V und DC konfiguriert)
2xE5-2630 (12C/24T)
64GB RAM
LSI-MR9271-8i Controller
4x900GB SAS 10k rpm (als Raid5 mit 3 Platten + Spare)
VM's:
- TerminalServer (4C, 32GB RAM)
- SQL Datenbank (4C, 16GB RAM)
- Entwicklungsumgebung für WaWi-System (2C, 2GB RAM)
Nach einigen Tests mussten wir mit Schrecken feststellen, welche Performance das System liefert. Nicht nur das ein Vorgang aus dem WaWi-System auf einem Laptop doppelt so schnell abläuft, auch der Zugriff direkt am Host scheint seine "Laggs" zu haben. Diese sind zwar nur minimal, aber sie sind vorhanden.
Auszug aus einem HDD_Bench mit CrystalDiskMark:
Sequential Read : 3373.574 MB/s
Sequential Write : 38.039 MB/s
Random Read 512KB : 2627.551 MB/s
Random Write 512KB : 32.909 MB/s
Random Read 4KB (QD=1) : 32.877 MB/s [ 8026.6 IOPS]
Random Write 4KB (QD=1) : 0.731 MB/s [ 178.6 IOPS]
Random Read 4KB (QD=32) : 259.857 MB/s [ 63441.7 IOPS]
Random Write 4KB (QD=32) : 3.067 MB/s [ 748.8 IOPS]
Nun meine Frage, da ich dazu wie gesagt nicht viel eindeutiges gefunden habe:
- Festplattencache ist deaktiviert --> Kann dieser aktiviert werden? Zusätzlich zu dem Raid-Controller-Cache?
- Ist das Raid5 überhaupt die richtige Konfiguration?
- Würde ein SSD-Cache-Controller etwas bringen?
Danke für eure Hilfe!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 257134
Url: https://administrator.de/contentid/257134
Ausgedruckt am: 25.11.2024 um 18:11 Uhr
23 Kommentare
Neuester Kommentar
Moin,
Hat denn der Controller einen Cache nebst Batterie? Soweit ich das den Specs von LSI entnehmen konnte, ist das ein optionales Zusatzmodul
Da streiten sich die Geister
Ich würde ein RAID 10 aufsetzen, gerade in Sachen Schreibgeschwindigkeit ist RAID5 grottig langsam (es muss ja bei jedem Schreibvorgang Parität berechnet und geschrieben werden)
RAID 10 verschwendet zwar etwas mehr Roh-Kapazität aber die Zeiten wo Festplatten teuer waren sind ja Geschichte.
Da habe ich leider keine Erfahrungswerte, was das unter Hyper-V bringt.
Gruß
Bernhard
Nun meine Frage, da ich dazu wie gesagt nicht viel eindeutiges gefunden habe:
- Festplattencache ist deaktiviert --> Kann dieser aktiviert werden? Zusätzlich zu dem Raid-Controller-Cache?
- Festplattencache ist deaktiviert --> Kann dieser aktiviert werden? Zusätzlich zu dem Raid-Controller-Cache?
Hat denn der Controller einen Cache nebst Batterie? Soweit ich das den Specs von LSI entnehmen konnte, ist das ein optionales Zusatzmodul
- Ist das Raid5 überhaupt die richtige Konfiguration?
Da streiten sich die Geister
Ich würde ein RAID 10 aufsetzen, gerade in Sachen Schreibgeschwindigkeit ist RAID5 grottig langsam (es muss ja bei jedem Schreibvorgang Parität berechnet und geschrieben werden)
RAID 10 verschwendet zwar etwas mehr Roh-Kapazität aber die Zeiten wo Festplatten teuer waren sind ja Geschichte.
- Würde ein SSD-Cache-Controller etwas bringen?
Da habe ich leider keine Erfahrungswerte, was das unter Hyper-V bringt.
Gruß
Bernhard
1
Zitat von @siehe0815:
Nun meine Frage, da ich dazu wie gesagt nicht viel eindeutiges gefunden habe:
- Festplattencache ist deaktiviert --> Kann dieser aktiviert werden? Zusätzlich zu dem Raid-Controller-Cache?
Nun meine Frage, da ich dazu wie gesagt nicht viel eindeutiges gefunden habe:
- Festplattencache ist deaktiviert --> Kann dieser aktiviert werden? Zusätzlich zu dem Raid-Controller-Cache?
Moin,
Dieser kann aktiviert werden, ist aber ein guter einstieg ins das Russisch-Roulette. Dann hat der Controler keinem kontrolle mehr, was auf der Platte schon gelandet ist uind was beim nächsten "abschalten" verloren ist. Deswegen solerl man auch imerm eine BBU auf die Controller packen.
- Ist das Raid5 überhaupt die richtige Konfiguration?
Offensichtlich nicht. Warum macht Ihr kein RAID1 oder RAID10
- Würde ein SSD-Cache-Controller etwas bringen?
Ganz auf SSD im RAID1 wechseln würde ich sagen.
Danke für eure Hilfe!
gern geschehen.
Nochmal zusammengefaßt
Für Datenbankanwendugen wie z.B. eine WaWi ist es essentiell, die IOPS möglichst groß zu haben. RAID5 verschechtert diese, und zwar noch mehr als RAID1 (beim Schreiben).
lks
@mitglied: BernhardMeierrose
Danke für den Input. Ich beantworte direkt alles auf einmal.
- Der Cotroller hat 1GB DDR3 RAM als Cache. Eine BBU ist angeschlossen.
Danke für den Input. Ich beantworte direkt alles auf einmal.
- Der Cotroller hat 1GB DDR3 RAM als Cache. Eine BBU ist angeschlossen.
Offensichtlich nicht. Warum macht Ihr kein RAID1 oder RAID10
Die Konfiguration haben wir leider nicht vorgeben können. Wir sind jetzt zum Fehlerausbessern da. Aber ein Raid10 hatte ich sofort im Kopf.Ganz auf SSD im RAID1 wechseln würde ich sagen.
Der Gedanke liegt natürlich im Raum. Hat jemand Erfahrungen mit SSD's im Enterprise-Bereich?
Und SQL Server auf RAID5 ist schonmal eine Grundsätzlich schlechte Idee. Wie BernhardMeierrose schon geschrieben hat ist RAID5 nicht dafür gemacht um viele Schreibvorgänge abzuarbeiten.
Den Cache sollte man nur aktivieren, wenn der Controller auch eine BBU hat.
Wenn irgendwie möglich, dann 2 SSDs per RAID1 reinhängen und da die SQL DB drauf laufen lassen.
Den Cache sollte man nur aktivieren, wenn der Controller auch eine BBU hat.
Wenn irgendwie möglich, dann 2 SSDs per RAID1 reinhängen und da die SQL DB drauf laufen lassen.
Moin,
Auf DCs wird (lt. MS aus Sicherheitsgründen) standardmäßig der Schreibcache auf allen Volumes deaktiviert.
Das macht dem DC eigentlich nichts, Hyper-V und den VMs dagegen schon, wie du ja gerade siehst.
Installiere dir eine VM, die du zum DC hochstufst und dann demote den W2012 zum normalen Mitgliedsserver.
Jetzt kannst du auch wieder den Cache einschalten. Das sollte die Performance deutlich erhöhen.
WS2012 (mit Hyper-V und DC konfiguriert)
Hier ist dein Problem! Der Hyper-V Host darf kein DC sein.Auf DCs wird (lt. MS aus Sicherheitsgründen) standardmäßig der Schreibcache auf allen Volumes deaktiviert.
Das macht dem DC eigentlich nichts, Hyper-V und den VMs dagegen schon, wie du ja gerade siehst.
Installiere dir eine VM, die du zum DC hochstufst und dann demote den W2012 zum normalen Mitgliedsserver.
Jetzt kannst du auch wieder den Cache einschalten. Das sollte die Performance deutlich erhöhen.
Hallo,
da kein "offizieller" Server-Name genannt wurde, gehe ich mal davon aus es handelt sich um einen "Eigenbau-" Server (wäre schon mal nicht so gut).
Lese ich das richtig: der Server ist Virtualisierungs-Host und gleichzeitg ADC? Ganz schlecht!
Bei einem RAID5 gilt: je mehr Spindeln (Festplatten) um so besser --> die R/W-Vorgänge verteilen sich dann auf mehr HDs.
Generell ist RAID5 aber ein Kompromiss aus Sicherheit, Performance und Kapazität. Ein RAID0 bringt deutlich mehr Performance zu lasten der Sicherheit. Besser ist dann RAID10, was die Sicherheit zu lasten der Kapazität erhöht. Um ein vergleichbares RAID10-System aufzubauen, brauchst Du 2x3+1=7HDs.
Auch hier gilt: je mehr Spindeln um so besser --> also lieber kleinere Platten, dafür mehr. (Ist natürlich kontraproduktiv bezüglich Energieverbrauch und Kosten, aber alles hat seinen Preis).
Die Aktivierung eines Caches bringt immer etwas (RAM läßt sich eben immer schneller lesen und beschreiben). Bei einem Server sollte man aber darauf achten, dass der Cache auf dem RAID-Controller mit einer Stütz-Batterie geschütz wird. Ob ein SSD-Cache etwas bringt, bin ich mir nicht sicher, da der Zugriff der VMs auf die virtuellen Festplatten ja blockorientiert und nicht File-orientiert erfolgt. Aber das hängt sicher vom eingesetzten Controller ab.
Auch die Erstellung meherer RAID-Gruppen (zB eine separate RAID10-Gruppe für das DB-Laufwerk der WaWi) könnte Abhilfe schaffen.
In diesem Buch (allerdings für VMware; dass ist hier aber egal)
http://www.amazon.de/VMware-vSphere-umfassende-Handbuch-Computing/dp/38 ...
gibt es eine gute Abhandlung über die Thematik "Storage für VMs"
Jürgen
da kein "offizieller" Server-Name genannt wurde, gehe ich mal davon aus es handelt sich um einen "Eigenbau-" Server (wäre schon mal nicht so gut).
Lese ich das richtig: der Server ist Virtualisierungs-Host und gleichzeitg ADC? Ganz schlecht!
Bei einem RAID5 gilt: je mehr Spindeln (Festplatten) um so besser --> die R/W-Vorgänge verteilen sich dann auf mehr HDs.
Generell ist RAID5 aber ein Kompromiss aus Sicherheit, Performance und Kapazität. Ein RAID0 bringt deutlich mehr Performance zu lasten der Sicherheit. Besser ist dann RAID10, was die Sicherheit zu lasten der Kapazität erhöht. Um ein vergleichbares RAID10-System aufzubauen, brauchst Du 2x3+1=7HDs.
Auch hier gilt: je mehr Spindeln um so besser --> also lieber kleinere Platten, dafür mehr. (Ist natürlich kontraproduktiv bezüglich Energieverbrauch und Kosten, aber alles hat seinen Preis).
Die Aktivierung eines Caches bringt immer etwas (RAM läßt sich eben immer schneller lesen und beschreiben). Bei einem Server sollte man aber darauf achten, dass der Cache auf dem RAID-Controller mit einer Stütz-Batterie geschütz wird. Ob ein SSD-Cache etwas bringt, bin ich mir nicht sicher, da der Zugriff der VMs auf die virtuellen Festplatten ja blockorientiert und nicht File-orientiert erfolgt. Aber das hängt sicher vom eingesetzten Controller ab.
Auch die Erstellung meherer RAID-Gruppen (zB eine separate RAID10-Gruppe für das DB-Laufwerk der WaWi) könnte Abhilfe schaffen.
In diesem Buch (allerdings für VMware; dass ist hier aber egal)
http://www.amazon.de/VMware-vSphere-umfassende-Handbuch-Computing/dp/38 ...
gibt es eine gute Abhandlung über die Thematik "Storage für VMs"
Jürgen
Zitat von @siehe0815:
> Ganz auf SSD im RAID1 wechseln würde ich sagen.
Der Gedanke liegt natürlich im Raum. Hat jemand Erfahrungen mit SSD's im Enterprise-Bereich?
> Ganz auf SSD im RAID1 wechseln würde ich sagen.
Der Gedanke liegt natürlich im Raum. Hat jemand Erfahrungen mit SSD's im Enterprise-Bereich?
Funktionieren ordentlich. Nur muß man sich klarmachen, daß die anders als HDDs funktionieren und im Fehlerfall es schwieriger bis unmöglich ist, da noch daten herunterzukratzen. man muß als im Vorfeld genügend Redundanz schaffen udn für funktionierende Backup- und Recovery-prozediuren sorgen.
Und beim entsorgen sind die SSD kritischer, weln man die Sektoren nciht einfach so übescheiben kann, weil nicht die Kontrolle hat, welche zellen wirklich geschrieben werden.
lks
Hallo @goscho,
das Problem mit dem DC habe ich auch schon erwähnt. Deine Lösung (DC als VM auf Hyper-V-Server, der in der Domäne des DCs ist) hat aber einen entscheidenden Haken: Wenn Du den Host hoch fährst, läuft der DC in der VM ja noch nicht. Also keine Anmeldung an der Domäne möglich --> keine Verwaltung der VMs möglich. Das typische Henne - Ei - Problem.
Aus diesem Grund sollte der (primäre) DC in einer solchen Konstellation immer in "Blech" ausgeführt werden.
Jürgen
das Problem mit dem DC habe ich auch schon erwähnt. Deine Lösung (DC als VM auf Hyper-V-Server, der in der Domäne des DCs ist) hat aber einen entscheidenden Haken: Wenn Du den Host hoch fährst, läuft der DC in der VM ja noch nicht. Also keine Anmeldung an der Domäne möglich --> keine Verwaltung der VMs möglich. Das typische Henne - Ei - Problem.
Aus diesem Grund sollte der (primäre) DC in einer solchen Konstellation immer in "Blech" ausgeführt werden.
Jürgen
> Offensichtlich nicht. Warum macht Ihr kein RAID1 oder RAID10
Die Konfiguration haben wir leider nicht vorgeben können. Wir sind jetzt zum Fehlerausbessern da. Aber ein Raid10 hatte ich
sofort im Kopf.
Dann würde ich empfehlen, dieses vom Kopf auf die Platten zu übertragen
Raid1 mit SSD-Platten wäre natürlich auch fesch, aber so ganz kosten-neutral ist die Nummer nicht.
Da Du einen Cache mit BBU hast, kannst Du auch den Cache-Modus des Controllers auf write-back umschalten, das bringt auch noch ne Schippe Schreib-Performance zusätzlich.
bzgl DC/Schreibcache: Wenn mich nicht alles täuscht, deaktiviert Windows nur den OS-eigenen Cache und eben nicht den Controller-Cache, von daher sehe ich das nicht als Baustelle an.
@mitglied: chiefteddy
Der Server ist von exone (Challenge G4). Kein Eigenbau.
Das Problem mit dem ADC ist natürlich enorm und mir nicht bewusst gewesen. Macht aber Sinn. Die Möglichkeit den ADC in eine VM zu legen würde funktionieren, da der Server im Alltagsgeschäft nicht heruntergefahren wird und somit auch die Anmeldung an die Domäne nicht beeinträchtigt ist. Die anderen VM's können ja verzögert werden.
Wir sind jetzt soweit die Maschine neu aufzusetzten. Dabei wird am Ende ein Raid10 (SAS) und ein Raid1 (SSD) zur Verfügung stehen. Backups der VM's sind soweit kein Problem. Um die Neuinstallation des ADC zu verhindern würde ich gerne die physikalische WS2012 Installation (vom alten Host) virutalisieren. Das sollte mit "VMware vCenter Converter Standalone" einwandfrei funktionieren, richtig?
Da ich derartige Vorgänge noch nicht vollzogen habe, wird bei der Einrichtung des "alten Hosts (ADC)" als VM direkt die bestehende Domäne wieder übernommen? Oder muss der ADC neu eingerichtet werden?
Andernfalls wird einen neue WS2012 Installation als ADC ernannt (VM), gibt es dabei einen Mechanismus, welcher erkennt, das der bestehende ADC degradiert werden muss?
Der Server ist von exone (Challenge G4). Kein Eigenbau.
Das Problem mit dem ADC ist natürlich enorm und mir nicht bewusst gewesen. Macht aber Sinn. Die Möglichkeit den ADC in eine VM zu legen würde funktionieren, da der Server im Alltagsgeschäft nicht heruntergefahren wird und somit auch die Anmeldung an die Domäne nicht beeinträchtigt ist. Die anderen VM's können ja verzögert werden.
Wir sind jetzt soweit die Maschine neu aufzusetzten. Dabei wird am Ende ein Raid10 (SAS) und ein Raid1 (SSD) zur Verfügung stehen. Backups der VM's sind soweit kein Problem. Um die Neuinstallation des ADC zu verhindern würde ich gerne die physikalische WS2012 Installation (vom alten Host) virutalisieren. Das sollte mit "VMware vCenter Converter Standalone" einwandfrei funktionieren, richtig?
Da ich derartige Vorgänge noch nicht vollzogen habe, wird bei der Einrichtung des "alten Hosts (ADC)" als VM direkt die bestehende Domäne wieder übernommen? Oder muss der ADC neu eingerichtet werden?
Andernfalls wird einen neue WS2012 Installation als ADC ernannt (VM), gibt es dabei einen Mechanismus, welcher erkennt, das der bestehende ADC degradiert werden muss?
Hallo,
ich würde Dir nach wie vor dazu raten den DC in "Blech" aufzusetzen. Ich arbeite zwar mit vSphere 5.5 aber hier ist das Problem ähnlich. Solange der DC nich läuft, kannst Du Dich nicht bei vSphere anmelden. Wenn Du keinen Zugang zu vSphere hast, kannst Du den DC nicht starten (Henne-Ei-Problem). Bei mir ist das Problem nicht so gravierent, da ich als Verzeichnisdienst eDirectory von Novell im Einsatz habe und der vSphere-Server nicht in einer Domäne ist.
Bei Hyper-V ist aber das System-Center zur Administration in das AD integriert und damit MUSS der DC laufen, bevor Du etwas administrieren kannst. Und wie willst Du etwas administrieren (zB. den DC starten) wenn Du Dich nicht am AD anmelden kannst und damit keinen Zugang zum System-Center hast? Dabei ist es egal, ob Du den Host häufig oder selten neu startest.
Prinzipiell kannst Du mit dem Converter von VMware von einer phys. Maschine eine VM machen (habe ich bei der Umstellung auf die virtuelle Infrastruktur bei mir mehrfach gemacht). In Deinem Fall würde ich aber einen anderen Weg gehen, damit die Hyper-V-Funktion nicht mit virtualisiert wird. Ich würde einen 2. DC in die vorhandene Domäne als VM neu installieren. Dann würde ich den neuen DC zum Master hoch stufen und anschließend den alten DC von seiner Rolle befreien.
Damit stellst Du sicher, dass das AD korrekt übernommen wird und keine Timestamp-Probleme in der AD-Datenbank auftreten.
Jürgen
ich würde Dir nach wie vor dazu raten den DC in "Blech" aufzusetzen. Ich arbeite zwar mit vSphere 5.5 aber hier ist das Problem ähnlich. Solange der DC nich läuft, kannst Du Dich nicht bei vSphere anmelden. Wenn Du keinen Zugang zu vSphere hast, kannst Du den DC nicht starten (Henne-Ei-Problem). Bei mir ist das Problem nicht so gravierent, da ich als Verzeichnisdienst eDirectory von Novell im Einsatz habe und der vSphere-Server nicht in einer Domäne ist.
Bei Hyper-V ist aber das System-Center zur Administration in das AD integriert und damit MUSS der DC laufen, bevor Du etwas administrieren kannst. Und wie willst Du etwas administrieren (zB. den DC starten) wenn Du Dich nicht am AD anmelden kannst und damit keinen Zugang zum System-Center hast? Dabei ist es egal, ob Du den Host häufig oder selten neu startest.
Prinzipiell kannst Du mit dem Converter von VMware von einer phys. Maschine eine VM machen (habe ich bei der Umstellung auf die virtuelle Infrastruktur bei mir mehrfach gemacht). In Deinem Fall würde ich aber einen anderen Weg gehen, damit die Hyper-V-Funktion nicht mit virtualisiert wird. Ich würde einen 2. DC in die vorhandene Domäne als VM neu installieren. Dann würde ich den neuen DC zum Master hoch stufen und anschließend den alten DC von seiner Rolle befreien.
Damit stellst Du sicher, dass das AD korrekt übernommen wird und keine Timestamp-Probleme in der AD-Datenbank auftreten.
Jürgen
Hallo,
Gruß,
Peter
Zitat von @BernhardMeierrose:
Wenn mich nicht alles täuscht, deaktiviert Windows nur den OS-eigenen Cache
Korrekt, und den von der Platte wo dein SYSVOL liegt. Hat dein SYSVOL eine eigene Spindel trifft es nur diese Platte (aus Windows Server Sicht).Wenn mich nicht alles täuscht, deaktiviert Windows nur den OS-eigenen Cache
Gruß,
Peter
NACHTRAG:
Was mir noch eingefallen ist. Der Kunde verwendet RDX Laufwerke als Backup (täglich). Laut Tandenberg sind diese mit einem Hypervisor nicht kompatibel. Habt ihr Erfahrungen oder Workarounds für die Einbindung? Oder Ideen für eine alternative Backuplösung auf die RDX-Platten?
Was mir noch eingefallen ist. Der Kunde verwendet RDX Laufwerke als Backup (täglich). Laut Tandenberg sind diese mit einem Hypervisor nicht kompatibel. Habt ihr Erfahrungen oder Workarounds für die Einbindung? Oder Ideen für eine alternative Backuplösung auf die RDX-Platten?
Hallo,
Gruß,
Peter
Zitat von @siehe0815:
Die Möglichkeit den ADC in eine VM zu legen würde funktionieren, da der Server im Alltagsgeschäft nicht heruntergefahren wird und somit auch die Anmeldung an die Domäne nicht beeinträchtigt ist.
Die Frage ist doch wie du dich an dein Hyper-V anmeldest wenn deine VM mit den DC warum auch immer nicht gestartet ist. Daher ein Blech... Oder dein Hyper-V bleibt in einer Workgroup (mit allen folgen) denn als Memberserver braucht die auch wieder den DC um sich dort an zu melden.... (Henne - EI) Die Möglichkeit den ADC in eine VM zu legen würde funktionieren, da der Server im Alltagsgeschäft nicht heruntergefahren wird und somit auch die Anmeldung an die Domäne nicht beeinträchtigt ist.
Das sollte mit "VMware vCenter Converter Standalone" einwandfrei funktionieren, richtig?
Wenn du auf VMWare Produkte gehen willst schon.... Du willst aber doch zu Hyper-V. Und dort sind die Eigenheiten von VMWare eher hinderlich (jedenfalls nicht sauber). Es gibt Disk2vhd, Backup und dann Wiederherstellung, Image ziehen und und und ...... Beachte: VMWare ungleich Microsoft bzw. ESXi ungleich Hyper-V. Auch etliche Datensicherungs-Imageprogramme beherrschen dies. z.B: Active Image Protector von NetJapan .....Andernfalls wird einen neue WS2012 Installation als ADC ernannt (VM), gibt es dabei einen Mechanismus, welcher erkennt, das der bestehende ADC degradiert werden muss?
Wie stellst du dir so ein Mechanismus denn vor? Wie soll das funktionieren? Und dir ist klar was bei einer neuen Domäne an folgen auf dich zukommen?Gruß,
Peter
Zitat von @chiefteddy:
Ich arbeite zwar mit vSphere 5.5 aber hier ist
das Problem ähnlich. Solange der DC nich läuft, kannst Du Dich nicht bei vSphere anmelden. Wenn Du keinen Zugang zu
vSphere hast, kannst Du den DC nicht starten (Henne-Ei-Problem).
Ich arbeite zwar mit vSphere 5.5 aber hier ist
das Problem ähnlich. Solange der DC nich läuft, kannst Du Dich nicht bei vSphere anmelden. Wenn Du keinen Zugang zu
vSphere hast, kannst Du den DC nicht starten (Henne-Ei-Problem).
Öhm, schau mal in der Host-Konfiguration nach, da kannst Du den Autostart von VMs aktivieren. Damit fährt man üblicherweise den DC und vCenter automatisch als erstes hoch. (und den Rest der VMs z.B. mit leichter zeitlicher Verzögerung)
Hallo,
Hier solltest du aber jetzt mal definieren was da nicht Kompatibel ist und was du erwartest.
Und dein
Was soll gesichert werden?
Wie soll gesichert werden?
Wie Oft soll gesichert werden?
Wohin soll gesichert werden?
Welche Datenbanksysteme sollen wie oft wohin gesichert werden?
Exchange soll wie oft wohin gesichert werden?
Reicht eine Sicherung ala VEEM oder muss es ein AIP for Hyper.V Enterprise sein oder reicht aus den einzelnen laufenden VMs heraus selbst zu sichern nach iSCI, SAN, NAS, FTP, Cloud? https://www.netjapan.eu/de/products/activeimage-protector/hyper-v/featur ...
Gruß,
Peter
Hier solltest du aber jetzt mal definieren was da nicht Kompatibel ist und was du erwartest.
Habt ihr Erfahrungen oder Workarounds für die Einbindung?
Es kommt darauf an was du wo wie warum eingebunden haben willst.Oder Ideen für eine alternative Backuplösung auf die RDX-Platten?
Was wird denn jetzt verwendet?Und dein
Backups der VM's sind soweit kein Problem
bedeutet jetzt was?Was soll gesichert werden?
Wie soll gesichert werden?
Wie Oft soll gesichert werden?
Wohin soll gesichert werden?
Welche Datenbanksysteme sollen wie oft wohin gesichert werden?
Exchange soll wie oft wohin gesichert werden?
Reicht eine Sicherung ala VEEM oder muss es ein AIP for Hyper.V Enterprise sein oder reicht aus den einzelnen laufenden VMs heraus selbst zu sichern nach iSCI, SAN, NAS, FTP, Cloud? https://www.netjapan.eu/de/products/activeimage-protector/hyper-v/featur ...
Gruß,
Peter
> Das sollte mit "VMware vCenter Converter Standalone" einwandfrei funktionieren, richtig?
Wenn du auf VMWare Produkte gehen willst schon.... Du willst aber doch zu Hyper-V. Und dort sind die Eigenheiten von VMWare eher
hinderlich (jedenfalls nicht sauber).
Was für unsaubere Eigenheiten sollen das konkret sein ?Wenn du auf VMWare Produkte gehen willst schon.... Du willst aber doch zu Hyper-V. Und dort sind die Eigenheiten von VMWare eher
hinderlich (jedenfalls nicht sauber).
Hallo,
Produktspezifische Treiber?
Gruß,
Peter
Produktspezifische Treiber?
Gruß,
Peter
Hallo @BernhardMeierrose,
das ist mir schon bewußt und auch so eingestellt. Doch es gibt Empfehlungen der Hersteller und praktische Erfahrungen. Und VMware empfiehlt für der vSphere-Server zB "Blech". Natürlich geht es auch anders, aber man muß sich über die Konsequenzen Gedanken machen. Ich habe in meiner Wndows-Domäne (andere Abteilung mit Anforderungen, die nur mit AD gehen) 2 DCs zur Ausfallsicherheit. Einer ist in "Blech" (ein alter, ausgedienter Server erhält so sein "Gnadenbrot") und einer ist als VM ausgeführt.
Das mit dem Starten war ja nur ein Bsp. Ich hatte bei mir zB mal den Fall, dass die vSphere-VM durch einen dummen Konfigurationsfehler nicht automatisch startete. Fiel im "Normalbetrieb" gar nicht auf. Nach einem längeren Spannungsausfall hatte ich dann aber das Problem. Zum Glück kann man auf die ESXi-Host ja noch direkt zugreifen.
Bei einem Host mag ja vieles noch gehen, wenn Du aber einen Cluster hast (bei mir sind es 3 Hosts), geht vieles im "Havariefall" eben nur über die Management-Oberfläche. Und die ist bei Hyper-V nun mal das System-Center mit AD-Anbindung.
Wir müssen nun nicht über alle denkbaren Eventualitäten diskutieren. Ich habe mich an die "best practice" gehalten und bin damit immer gut gefahren.
Jürgen
das ist mir schon bewußt und auch so eingestellt. Doch es gibt Empfehlungen der Hersteller und praktische Erfahrungen. Und VMware empfiehlt für der vSphere-Server zB "Blech". Natürlich geht es auch anders, aber man muß sich über die Konsequenzen Gedanken machen. Ich habe in meiner Wndows-Domäne (andere Abteilung mit Anforderungen, die nur mit AD gehen) 2 DCs zur Ausfallsicherheit. Einer ist in "Blech" (ein alter, ausgedienter Server erhält so sein "Gnadenbrot") und einer ist als VM ausgeführt.
Das mit dem Starten war ja nur ein Bsp. Ich hatte bei mir zB mal den Fall, dass die vSphere-VM durch einen dummen Konfigurationsfehler nicht automatisch startete. Fiel im "Normalbetrieb" gar nicht auf. Nach einem längeren Spannungsausfall hatte ich dann aber das Problem. Zum Glück kann man auf die ESXi-Host ja noch direkt zugreifen.
Bei einem Host mag ja vieles noch gehen, wenn Du aber einen Cluster hast (bei mir sind es 3 Hosts), geht vieles im "Havariefall" eben nur über die Management-Oberfläche. Und die ist bei Hyper-V nun mal das System-Center mit AD-Anbindung.
Wir müssen nun nicht über alle denkbaren Eventualitäten diskutieren. Ich habe mich an die "best practice" gehalten und bin damit immer gut gefahren.
Jürgen
Moin Jürgen,
das ist mir schon bewußt und auch so eingestellt. Doch es gibt Empfehlungen der Hersteller und praktische Erfahrungen. Und
VMware empfiehlt für der vSphere-Server zB "Blech". Natürlich geht es auch anders, aber man muß sich
über die Konsequenzen Gedanken machen.
Auch auf die Gefahr hin, dass das hier in Richtung Off-Topic driftet, VMWare empfiehlt seit VSphere 4.1 den Einsatz von vCenter in einer virtuellen Maschine um z.B. eine Absicherung per HA zugewährleisten bzw vMotion für die Migration des vCenters zu nutzen. Der vCenter Server wird ja auch als Linux-basierte Appliance angeboten, das würde ja kaum Sinn machen wenn die den Einsatz von Blech empfehlen würden.
In allen Clustern, die ich bisher in Betrieb genommen habe, habe ich das auch als VM gemacht und auch nach längerem Stromausfall kam der Cluster sauber wieder hoch.
Von daher spricht auch in der Konstellation hier rein gar nichts gegen den Einsatz von VMWare (ob mit oder ohne vCenter sei dahingestellt)
das ist mir schon bewußt und auch so eingestellt. Doch es gibt Empfehlungen der Hersteller und praktische Erfahrungen. Und
VMware empfiehlt für der vSphere-Server zB "Blech". Natürlich geht es auch anders, aber man muß sich
über die Konsequenzen Gedanken machen.
Auch auf die Gefahr hin, dass das hier in Richtung Off-Topic driftet, VMWare empfiehlt seit VSphere 4.1 den Einsatz von vCenter in einer virtuellen Maschine um z.B. eine Absicherung per HA zugewährleisten bzw vMotion für die Migration des vCenters zu nutzen. Der vCenter Server wird ja auch als Linux-basierte Appliance angeboten, das würde ja kaum Sinn machen wenn die den Einsatz von Blech empfehlen würden.
In allen Clustern, die ich bisher in Betrieb genommen habe, habe ich das auch als VM gemacht und auch nach längerem Stromausfall kam der Cluster sauber wieder hoch.
Von daher spricht auch in der Konstellation hier rein gar nichts gegen den Einsatz von VMWare (ob mit oder ohne vCenter sei dahingestellt)
Vorsorglich auf "Gelöst" gestellt, da es wirklich OffTopic ist!
Danke für die Hilfe...
Danke für die Hilfe...
Hallo @bernhard Meierrose,
ich stimme Dir ausdrücklich zu wenn Du vCenter als VM betreibs. Ich mache es ja auch so. Aber ohne laufendes vCenter ist die Administration eines VMware-Clusters doch sehr eingeschränkt. Also muß man sich vorher Gedanken machen, wie man vCenter unter allen Umständen wieder zum Laufen bekommt. Für vMotion brauche ich vCenter! Und wenn vCenter nicht läuft (warum auch immer) und ich brauche zum Lösen des Problems vMotion, dann habe ich ein Problem. Ob das bei vCenter in "Blech" leichter zu lösen ist, kann man sicher diskutieren.
Mein Problem entstand durch eine Fehlkonfiguration und hatte nichts mit VMware zu tun. Das Problem hatte aber ich. Und mußte es lösen.
Die Ausgangsfrage war aber nicht vSphere sondern der DC in einer virtualisierten Umgebung mit Hyper-V. Und hier war meine Empfehlung den DC in "Blech" und einen 2. DC aus Redundanz-Gründen als VM.
Ich betreibe eine (produktive) Domäne grundsätzlich immer aus Redundanzgründen mit mindst. 2 DCs, in der Regel einer davon in "Blech". Das hat sich bei mir bewährt. Und wenn mich jemand nach meiner Meinung fragt, kommuniziere ich das auch so. Andere mögen aus ihrem Wissen und ihren Erfahrungen andere Empfehlungen geben. Der Fragesteller kann sich dann die eine oder andere Meinung zu eigen machen.
Und in dem konkreten Fall (und um den ging es bei der Fragestellung) bleibe ich bei meiner Empfehlung, weil ich es so machen würde; weil es meinem Wissen und meinen Erfahrungen entspricht.
Jürgen
PS: Ansonsten schließe ich mich dem Fragesteller an: OT
ich stimme Dir ausdrücklich zu wenn Du vCenter als VM betreibs. Ich mache es ja auch so. Aber ohne laufendes vCenter ist die Administration eines VMware-Clusters doch sehr eingeschränkt. Also muß man sich vorher Gedanken machen, wie man vCenter unter allen Umständen wieder zum Laufen bekommt. Für vMotion brauche ich vCenter! Und wenn vCenter nicht läuft (warum auch immer) und ich brauche zum Lösen des Problems vMotion, dann habe ich ein Problem. Ob das bei vCenter in "Blech" leichter zu lösen ist, kann man sicher diskutieren.
Mein Problem entstand durch eine Fehlkonfiguration und hatte nichts mit VMware zu tun. Das Problem hatte aber ich. Und mußte es lösen.
Die Ausgangsfrage war aber nicht vSphere sondern der DC in einer virtualisierten Umgebung mit Hyper-V. Und hier war meine Empfehlung den DC in "Blech" und einen 2. DC aus Redundanz-Gründen als VM.
Ich betreibe eine (produktive) Domäne grundsätzlich immer aus Redundanzgründen mit mindst. 2 DCs, in der Regel einer davon in "Blech". Das hat sich bei mir bewährt. Und wenn mich jemand nach meiner Meinung fragt, kommuniziere ich das auch so. Andere mögen aus ihrem Wissen und ihren Erfahrungen andere Empfehlungen geben. Der Fragesteller kann sich dann die eine oder andere Meinung zu eigen machen.
Und in dem konkreten Fall (und um den ging es bei der Fragestellung) bleibe ich bei meiner Empfehlung, weil ich es so machen würde; weil es meinem Wissen und meinen Erfahrungen entspricht.
Jürgen
PS: Ansonsten schließe ich mich dem Fragesteller an: OT
Zitat von @chiefteddy:
Hallo @goscho,
das Problem mit dem DC habe ich auch schon erwähnt. Deine Lösung (DC als VM auf Hyper-V-Server, der in der Domäne
des DCs ist) hat aber einen entscheidenden Haken: Wenn Du den Host hoch fährst, läuft der DC in der VM ja noch nicht.
Also keine Anmeldung an der Domäne möglich --> keine Verwaltung der VMs möglich. Das typische Henne - Ei -
Problem.
Das ist kein Problem, außer man hat einen Cluster.Hallo @goscho,
das Problem mit dem DC habe ich auch schon erwähnt. Deine Lösung (DC als VM auf Hyper-V-Server, der in der Domäne
des DCs ist) hat aber einen entscheidenden Haken: Wenn Du den Host hoch fährst, läuft der DC in der VM ja noch nicht.
Also keine Anmeldung an der Domäne möglich --> keine Verwaltung der VMs möglich. Das typische Henne - Ei -
Problem.
Aus diesem Grund sollte der (primäre) DC in einer solchen Konstellation immer in "Blech" ausgeführt werden.
Natürlich ist es schöner einen zusätzlichen DC in Blech zu haben.Manchmal will man aber diese Zusatzlizenzen nicht aufbringen bzw. das weitere Gerät, welches Stromkosten erzeugt.
Bei Hyper-V ist es kein Problem, wenn der DC nur als VM vorliegt.
Einerseits kann man das in Hyper-V so konfigurieren, dass der DC zuerst automatisch startet und alle anderen VMs verzögert.
Andererseits ist es auch noch möglich, sich am Hyper-V-Host mit den lokalen Credentials anzumelden, so der DC mal nicht automatisch starten sollte.
Ich habe das bei mir jetzt so realisiert, nachdem ich über ein halbes Jahr einen W2K3-DC in Blech habe weiterlaufen lassen, der nur für die Ausfallsicherheit da war.
