Horstenberg
-
Gesamte Inhalte
139 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von Horstenberg
-
-
vor 2 Stunden schrieb Weingeist:
Die Storage-Pools sind schon auch geeignet als RAID-Controller-Ersatz. Ist absolut robust genug. Eigentlich sogar robuster, da ein Gerät weniger in der Kette (!bitte erst alles lesen!). Mittlerweile setze ich Storage Pools doch ca. 7 Jahre in diversen Projekten produktiv ein. Quasi seit es sie gibt. Anfangs nur für VDI mittlerweile für alles. Schlechter oder besser als Hardware-RAID kann man nicht wirklich pauschal beantworten. Hat beides Vorzüge und Nachteile.
Es kommt wie bei allem halt sehr stark auf die Implementierung und die Anforderungen an. Hardware-RAID ist halt einstecken, konfigurieren, fertig. Fehlerquelle extrem gering. Aufwand im Fehlerfall auch gering. Mittlerweile hat z.Bsp. Broadcom (LSI) auch vernünftiges NVMe RAID mit U.2-Laufwerken. Insofern kann man es sich schon überlegen wieder nen Hardware-RAID aufzubauen. Die neuen Controller sind sogar ziemlich schnell. Das wurde anfangs total verschlafen. Das Problem ist dann eher, das wirklich gute Zeugs von einem der grossen Herstellern in sinnvoller Gesamt-Austattung unter einen Hut zu bekommen. Meist endet man irgendwann bei Supermicro.
Storage Pools sind dagegen definitiv nicht trivial. Weder in der korrekten Erstellung noch dem Unterhalt. Man hat sehr viele Möglichkeiten einen kompletten Schwachsinn zusammenzuzimmern der am Ende sogar läuft und dann plötzlich total versagt. Die Reparatur ist dann sehr aufwendig bis nicht möglich. Man sollte sich schon sehr intensiv mit Storage Pools befassen und dessen Eigenheiten und insbesondere Schwächen kennen bevor man es tatsächlich produktiv einsetzt. Sprich Fehlerszenarien durchgehen, Tests mit Stromausfällen, Plattenausfälle, Sektorfehler, grosse Dateien verschieben, zu gross konfigurierte Thin-Volumes und und und.
Mein Fazit für oder gegen Storage Spaces: Storage Pools sind quasi eine bewusste Entscheidung für ein ziemlich mächtiges, flexibles Stück Software welches richtig eingesetzt viel Spass bereitet, falsch aber extrem viel Kummer. Quasi die Eierlegende Wollmilchsau die beim falschen Futter, Bewegung oder Pfleger sofort wegstirbt. ;)
Man sollte auch immer einen allfälligen Nachfolger im Hinterkopf haben. Die wenigsten IT-Fachleute sind so mit Storage Spaces vertraut, dass man Ihnen gefahrlos eine Umgebung "überlassen" kann. Als keine sinnvollen Hardware-Controller verfügbar waren, überwiegten die enormen Performance-Vorteile von SP mit SSD's oder NVMe gegenüber Hardware-Controller mit SSD's für mich klar. Heute denke ich, dass es vielleicht auch wieder nen Hardware-Controller sein dürfte. Ist halt viel Schmerzfreier die Umgebung in andere Hände zu übergeben - sofern man sowas wie ein Gewissen hat. ;)
Wahl der SSD: Das wichtigste ist bei allen SSD's die für Produktivdaten eingesetz werden die Wahl der Laufwerke. Die müssen über eigene Kondis für das Wegschreiben der ausstehenden Daten verfügen (weil die SSD's in der Regel die Commits rausgeben BEVOR effektiv geschrieben wurde). Dann müssen SSD's welche im RAID-Betrieb eingesetzt werden, über eine regelmässige und tiefe Latenz verfügen (Average und Max Latency müssen tief sein).
Bezüglich Speed ob man ihn braucht oder nicht: Ist er vorhanden, reklamiert niemand. Ist er es nicht, wird es mühsam zum ändern. Meine Erfahrung ist, dass in Kleinumgebungen der Speed immer relevant ist für irgend eine Aufgabe. Und sei es nur ein paar komisch programmierte Programme die aber sehr nützlich sind. Die anderen profitieren einfach auch davon, auch wenn es eigentlich unnötig ist. Mehrere Speed-Levels für Produktivdaten machen da selten Sinn. Auch kann man sich oft das teilweise aufwendige optimieren in der Regel schenken, das spart auch Zeit und somit Geld und die Umgebung bleibt einfach aufgebaut.
Auch die Taktrate der CPU nehme ich nichts unter 3GHZ. Bringt in Kleinumgebungen normal viel mehr als viele Kerne oder Dualsysteme. Vieles skaliert einfach nicht toll oder ist nach wie vor auf Single-Core ausgelegt. Die gefühlte Performance ist (Latenz) viel wichtiger ist als die effektive über längere Zeit und gesamthaft vefügbare Leistung. Es wird auch selten viel Performance "gemeinsam" benötigt. Es sind die Peaks die relevant sind. Für einen typischen KMU-Chef gibt es nichts schlimmeres als wenn der PC die Sanduhr bringt. Das ist offensichtliche, verlorene Zeit. Also immer frei nach dem Motto viel hilft viel zusammenstellen. ;)
OS auf gespiegelte schnelle Platten oder nicht: Würde ich immer machen. Zu schnell gibts nicht und RAID = eine Ausfallvariante weniger. Ich setze immer alles um was mit wenig Aufwand redundant gemacht werden kann und fängt bei der Stromversorgung an. Doppel-Online-USV, separat abgesichert, genügend Batteriekapazität, Strom-Switch für Geräte mit nur einem Netzteil etc. Da ist die Kohle z.B. viel besser aufgehoben als in einem zweiten Server oder einem teuren Dual-CPU-System.
Aber wie immer, alles ist irgendwoe Geschmackssache und kommt auf die Anforderungen und auch etwas auf die persönlichen Vorlieben an. Wie so oft.
Danke für Deinen sehr kenntnisreichen und wirklich sehr hilfreichen Beitrag.
Zwei Fragen:
Hast Du denn auch schon PCIe-NVMes in einen Storage Pool eingebunden?
Und wenn Du ohne HW-RAID-Controller arbeitest, aber das OS immer auf einen RAID legst, hast Du dann das Betriebssystem in einen Raid-1 auf dem Motherboard-Raid-Controller gelegt? Auf SATA-SSDs? In den Storage Pool geht das ja wohl nicht.
Nochmals danke für Deinen Beitrag!
vor 5 Stunden schrieb Nobbyaushb:Bezahlbares 10G auf Kupfer oder Glas gibt es bei UniFi
Ob der 16-Port 10 laut oder leise ist, kann ich nicht beantworten.
Der Schallpegel als auch der Stromverbrauch spielen bei uns eine untergeordnete Rolle.
Zu Hause habe ich jetzt zwei neue 2HE Server installiert, der Stromverbrauch ist von knapp 1kW auf etwas über 380W runter, jetzt nur noch 2,5“ Platten bzw. SSD.
Entsprechend weniger Wärme, obwohl ich im Winter der Keller damit heize..
Derzeit hat HP professionelle, lüfterlose Switches im Angebot. Die haben aber keinen 10-GBit oder SFP+-Port. Alles, was 10GBit hat, hat nach meiner Kenntnis Lüfter. Das ist leider der Killer, wenn der Switch in unmittelbarer Nähe von Arbeitsplätzen steht (da manche Switches ja wirklich an Flugzeuge erinnern).
vor 14 Stunden schrieb djmaker:Eventuell hilft der Artikel weiter:
https://docs.microsoft.com/de-de/windows-server/storage/storage-spaces/choosing-drives
Ich befürchte, der Artikel befasst sich mit Storage Spaces Direct und nicht mit Storage Pools. Aber, wie gesagt: Die Terminologie ist nicht wirklich einheitlich.
-
vor einer Stunde schrieb Nobbyaushb:
Wir haben im Serverbeicht nur noch 10G entweder Glas oder Kupfer, wenn die Leitungslängen es zulassen.
Hinter dem oben genannten 2-Node-Datacore-Cluster ist ein 2-Node-Hyper-V-Cluster mit Mellanox 100G angebunden.
Datendurchsatz im Cluster liegt in Bereichen von 3,2 bis 4,8 GB/s
Bei dem Test vor Inbetriebnahme (gemessen mit IOmeter in VM´s) haben wir etwa 50.000 IOPS gemessen - bei 20 VMs PRO VM...
Dass sind für mich unerreichbare Datendurchsatzraten. Ich brauche im wesentlichen lüfterlose und Silent-Konzepte, weil wir keinen separaten Serverraum haben. Ich hätte schon längst eine 10-GBit-Anbindung der Server, wenn es lüfterlose Switche mit entsprechender Leistung gibt. Ist übrigens bei vielen Settings in kleineren Unternehmen ein Thema und spricht bei der Server-Hardware für einen kompletten Abschied von Festplatten (Lautstärke, Lüfter).
-
vor 5 Minuten schrieb testperson:
Du könntest damit mal an Thomas Krenn rantreten. Evtl. haben die ja Erfahrungen damit oder äußern sich dazu.
Habe ich mir auch überlegt. Ich dachte, dass in der Praxis vielleicht schon viele solcher Lösungen im Einsatz sind...
Nachdem ich mich in den letzten Monaten viele Stunden mit Storage-Lösungen in KMU-Settings befasst habe, denke ich eigentlich, dass die Zeit der RAID-Controller mit Festplatten oder SSDs vorbei ist. Ich halte Ansätze wie den vroc-Ansatz von Intel (virtual raid on a chip) oder auch neue Schnittstellen wie Oculink und NVMe für deutlich überlegen, weil sie alte Flaschenhälse abschaffen und ganz neue Geschwindigkeiten ermöglichen. Natürlich ist das im heute noch üblichen 1-GBit-Netzwerk völlig überdimensioniert. Aber auch wenn Moore's Law nicht mehr gilt, ist auch sicher: Der Zahn der Zeit nagt an "alten" Raid-Lösungen. Da muss ich mir jetzt nicht mehr eine solche zulegen. --- Das muss aber natürlich jeder für sich selbst wissen, da habt Ihr Recht.
-
vor 2 Stunden schrieb NilsK:
Moin,
Raid macht man ja auch nicht wegen Geschwindigkeit. Ausfallsicherheit ist das Thema. Und da sind Storage Pools nur begrenzt als Lösung bekannt. Auch wenn der Hersteller da anderes behauptet.
Für mich klingt das ganze Konzept noch nicht ausreichend durchdacht. Wie testperson schon sagt, der Bedarf an schnellem Storage erschließt sich nicht ganz. Aber das kann man im Rahmen eines Forums auch nur begrenzt leisten.
Gruß, Nils
Danke für die Hinweise. So weitgehende Hinweise hatte ich aber auch gar nicht erwartet. Wenn man einen Server für die nächsten Jahre kauft, muss den jeder für sich selbst konzipieren. Die letzten Server habe ich in 2012 gekauft und die waren auch teils überdimensioniert und nicht passend für das Konzept, dafür halten sie auch heute noch gut deutlich anspruchsvollere Software aus.
Meine eigentliche Frage (Storage Pools und PCIe-NVMe-SSD) scheint allerdings nicht zu beantworten zu sein. Also unterstelle ich mal, dass es leider nicht geht. Jedenfalls habe ich nirgends im Internet gefunden, dass das Microsoft-Doc an dieser Stelle falsch ist und Herrn Joos kann man wohl nicht uneingeschränkt vertrauen.
-
vor 17 Minuten schrieb NilsK:
Moin,
Dass ein RAID Controller eine typische Fehlerquelle sei, wäre mir in 25 Jahren noch nicht untergekommen. Ich würde Storage Pools auch nicht mehr zutrauen als einem guten Hardware Raid. Storage Pools sind auch kein Raid.
Behalte bei dem Thema auch im Kopf, dass du bei direkt eingebauten Platten immer eine hohe Abhängigkeit vom konkreten Server hast. Mag zum Szenario passen, mag aber auch sein, dass das ein Irrweg ist. Das Host OS auf eine schnelle SSD zu legen, ist jedenfalls unnötig.
Generell: ich habe bei Thomas Joos schon zu oft schwerwiegende Fehler festgestellt, sodass ich davon abrate, sich auf seine Aussagen zu verlassen.
Gruß, Nils
Das Host OS lege ich auf eine M.2-NVMe-SSD, weil es praktisch ist (onboard M.2-Slot). Die M.2 kostet ja auch nicht die Welt (120 Euro oder so).
Zum RAID-Controller: Die Frage ist eher, warum ich heute noch einen brauche? Mit Cache und allen Software-Options kostet der schnell EUR 1.200 extra. Warum dann nicht auf superschnelle PCIe-NVMe-Karten gehen. Wenn, ja wenn man bei diesen eine gewisse Ausfallsicherheit schaffen kann, etwa durch Storage Pools...
vor 8 Minuten schrieb testperson:Ohne weitere Anforderungen zu kennen würde ich sagen, dass es in dem Szenario maximal "RDP" gibt, das von schnellem Storage profitieren könnte. Welche Anwendungen laufen denn später auf den RDSHs? Generell würde ich hier das Geld lieber in schnellere CPUs investieren, da Storage selten der begrenzende Faktor ist.
Derzeit laufen die Server als Hyper-V-Maschinen auf fast neun Jahre alten XEONs. Prozessorauslastung meist so um die null Prozent, außer beim Exchange 2019, der läuft aber "nur" mit 64 GB. Die Prozessorauslastung ist da meist auch unter 10%. Derzeit habe ich aber noch keinen TerminalServer.
Auf dem TerminalServer soll voraussichtlich MS Office laufen (wenn ich das lizenztechnisch gelöst habe) und (wenig anspruchsvolle) Spezialsoftware. Es gibt aber eine größere Datenbank, auf die wir zugreifen (leider homemade beim Spezialsoftwaremann, aber das ist hier nicht das Thema).
-
vor einer Stunde schrieb testperson:
Hi,
ich habe keine direkte oder hilfreiche Antwort, würde aber fragen, was du denn am Ende erreichen willst also was soll der Server später wofür bereitstellen? Eine weitere Frage wäre, brauchst du am Ende auch "so viel Disk / Cache Leistung"?
Gruß
Jan
Ich lasse mir (voraussichtlich bei Thomas Krenn) einen neuen Server zusammenbauen, mit 2x Intel Silver 4208 Prozessoren, 256 GB RAM. Auf dem Server laufen unter Hyper-V einige virtuelle Maschinen (alle Server 2016/19 und Windows 10):
- Insgesamt 9 Mal Server 2016/19: DC, Printserver, Exchange 2019, Mailstore, RDP, Web Application Proxy, ADFS, Work Folders, Fileserver.
- Dazu 4 - 10 Windows 10 Clients.
Bislang hatten alle Server bei mir Hardware-Raid. Die Raidkarte ist aber ein Single-Point-of-Failure und mir auch schon kaputt gegangen. SSD-Ausfälle hatte ich bis heute genau Null (bei jahrelangem, permanenten Office-Einsatz von zahlreichen SSDs).
Hinzu kommt, dass Raid-Controller wie Megaraid eine NVMe-SSD eher verlangsamen als beschleunigen.
Daher meine Überlegung: Weg von Hardware-Raid-Controllern. Den Server kaufe ich bei Thomas-Krenn mit höchstem Support-Level (Same Day). Dann muss ich mich aber - jenseits der 2xtäglichen Backups um Datenausfall kümmern.
Ergebnis zum Storage:
- Betriebssystem (Hyper-V-Server) geht auf eine interne M2-NVMe-SSD auf dem Mainboard.
- Drei 3,2TB-Samsung PCIe-NVMe-SSD binde ich als Storage-Pool zu einem RAID5 zusammen (= Parity), für die systemkritischen Hyper-V-Server.
- Weiterhin eine separate SATA-SSD (ohne RAID) 1,92 TB für die nicht systemkritischen Server/Clients.
Klingt für mich wie ein guter Plan. Wenn ich allerdings die 3,2TB Samsung PCIe-NVMe-SSDs nicht als Parity-Storage-Pool zusammenbinden kann, ist der Plan schon nicht mehr so toll.
-
Ich möchte in Windows Server 2019 Standard mehrere NVMe-SSDs, die über PCI-Express am Motherboard hängen, über Storagepools (dt. wohl "Speicherpools") zusammenbinden. Die Terminologie dazu im Internet ist nie einheitlich, da Storagepools wohl oft mit Storage Spaces Direct verwechselt wird.
Im Ergebnis möchte ich Storagepools als Software-Raid einsetzen (RAID-1 oder RAID-5-Ersatz), mit dem ich direkt angeschlossenen Speicher (DAS) bündele.
In diesem Link von Microsoft werden verschiedene Schnittstellen für Festplatten und SSDs genannt, mit denen Speicherpools möglichst sind. NVMe über PCI-E wird dort aber nicht als zulässiger Datenträgerbustyp genannt:
https://docs.microsoft.com/de-de/windows-server/storage/storage-spaces/deploy-standalone-storage-spaces
Im Buch zu Thomas Joos zu Windows Server 2019 liest man dann aber, dass "leistungsstarke NVMe-Datenträger integriert werden" können.
Also was denn nu? Ich möchte mir nicht einen Server mit teuren PCIe-NVMe zusammenstellen und dann kann ich diese nicht in einen Speicherpool einbinden.
-
vor 20 Stunden schrieb BOfH_666:
OK. Und aus welchem guten Grund würdest Du das dann tun?
Es gibt jedenfalls Gründe, von Exchange 2013 auf Exchange 2019 zu wechseln:
Exchange 2013 läuft zwar derzeit super-stabil auch mit den neuesten Outlook-Versionen, aber der Lifecycle ist drei Jahre kürzer.
Der zweite ist der Einfluss des Exchange auf das Gesamt-System. So wird nach der Support-Matrix ein Windows-Server-2019 Domain-Controller nur von Exchange 2019 und ab Exchange 2016CU7+x supported. Wer also einen 2019er-DC haben will und einen Exchange 2013 hat, muss umsteigen.
Da die Preise für Exchange 2019 nicht mehr deutlich über Exchange 2016 liegen, kann man dann direkt auf 2019 gehen.
Im Handling ist Exchange 2019 auch nicht so viel anders als 2013. Die eigentlichen Änderungen gab es imho zwischen Exchange 2010 und 2013.
-
Am 2.5.2020 um 21:19 schrieb MrCocktail:
Und ich sehe immer noch nicht den Vorteil von Exchange 2019 zu Exchange 2016 ...
Derzeit sehe ich den auch nicht, wegen des verringerten Supportzeitraums bei Exchange 2019. Aber mal sehen, ob Exchange 2016 auch mit Outlook 2022 oder Outlook 2025 zusammenarbeiten wird.
-
Hat jemand hier zwischenzeitlich Erfahrungen mit Exchange 2019 in kleineren Umgebungen mit weniger als dem empfohlenen Speicher gesammelt? Ein virtualisierter Exchange 2019 mit 64 GB für 30-40 Postfächer. Aushaltbar?
-
Was sagt die Remotedesktop-Lizenzierungsdiagnose?
Selbst wenn der Lizenzserver scheinbar überall richtig registriert ist, muss man dies noch in den Einstellungen des RD-Servers vornehmen. Hierzu etwa folgender Link:
Ist nirgendwo dokumentiert, ich musste dies aber schon mehrfach so machen, zuletzt sogar unter Windows Server 2019.
-
vor 43 Minuten schrieb NorbertFe:
Naja das ist jetzt auch nicht zwingenderweise preiswerter und von sinnvoll (wegen doppelt) rede ich da gar nicht erst. Läuft man halt nicht klöppelserver von Tarox, sondern irgendwo bei den drei großen. Auch da kann man in die sch... greifen, aber zumindest ist der Support sehr genau geregelt.
Nach sechs Jahren ist es jetzt tatsächlich preiswerter, insbesondere, wenn es jetzt noch ein paar Jahre läuft. Das war aber nicht mein Ziel. Ich beschäftige mich halt gerne mit Computern, mit der Hardware, der Software und der Programmierung, so als Hobby. Da ist eine Bastlerlösung halt interessanter. Manche haben zu schnelle Autos; das brauche ich glücklicherweise nicht.
-
vor 51 Minuten schrieb Nobbyaushb:
Exchange 2019 hat schon nur noch 5 Jahre, ebenso wie Server 2019... es sei denn, ich lese das falsch raus...
Mir geht es um den erweiterten (extended) Support. Windows Server 2019 hat extended Support bis Januar 2029. Scheint mir ein guter Deal zu sein.
Exchange 2019 hat extended Support nur bis Oktober 2025. Gegenüber Exchange 2013 (extended Support bis April 2023) gewinne ich damit also nicht viel. Deswegen warte ich auf Exchange 20XX, es sei denn, die auch nicht mehr ganz zuverlässige Exchange/Outlook Support-Matrix ändert sich (was etwa sein kann, wenn Exchange 2013 nicht mehr mit Outlook 365 zusammenarbeitet).
vor einer Stunde schrieb NorbertFe:Sehr pauschal. Keine Ahnung was du gekauft hast und welche umgebungsfaktoren zur Ablehnung führten.
Wieso auch?
Mir wurde 2010 über ein Systemhaus ein Server von Tarox verkauft. Wenn ich mich recht entsinne (ist lange her und ich will auch niemandem Unrecht tun!), war dann 2013 eine Verlängerung des Server-Supports nicht mehr möglich, den Grund dafür weiß ich nicht mehr. Das führte bei mir zu Zorn (?!) und dem Entschluss, mich davon nicht mehr abhängig zu machen. Daher entwickelte ich die Strategie "kaufe überdimensionierte Hardware, das auch noch zwei Mal, habe weitere Ersatzteile bei Dir und spare Dir den Support". Das ist zum Nachmachen natürlich nicht empfohlen, aber es funktioniert bei mir bestens. Ein Problem kann ich eigentlich nur bekommen, wenn beide Motherboards gleichzeitig abrauchen. Für die Festplatten, Raid-Controller, Netzteile usw. habe ich Ersatz vor Ort (den ich selbst einbauen kann). Nach sechs Jahren hat sich die Investition übrigens mehr als gelohnt. Bis auf Ram-Erweiterungen und ab-und-an Festplatten-Defekte war sechs Jahre nichts. Ist aber als Bastellösung nur Leuten zu empfehlen, die gerne an Computern schrauben (wie mich).
-
vor einer Stunde schrieb NorbertFe:
Also eigentlich sind bis zu 7 Jahre Support schon seit längerem üblich. Zumindest bei Dell.
In 2010 habe ich Server gekauft mit 3 Jahren Support. Naiv wie ich war, wollte ich den 2013 verlängern, was natürlich verweigert wurde. Darüber habe ich mich geärgert, deswegen habe ich in 2013 meine eigene Lösung geschaffen: Zwei Mal die exakt (nahezu) exakt gleiche Hardware, komplett überdimensioniert, die aufeinander repliziert, so dass ich notfalls mit einem Server weitermache, wenn der andere abraucht. Hat mir gute Dienste geleistet.
Eigentlich war für 2019 neue Hardware geplant, zusammen mit einem neuen Exchange. Bei 2019 hat mich aber der verkürzte Lifecycle enttäuscht, so dass ich jetzt auf Exchange 2022 warte (so es diesen geben wird) und die für diesen geltenden Hardware-Anforderungen. Die beiden Server aus 2013 laufen weiter brav, Ersatz-Festplatten habe ich zur Genüge bei mir liegen. Läuft also alles. Backups habe ich zur Genüge. Es bleibt also va das Risiko, dass beide Server innerhalb kurzer Zeit mit Hardware-Defekt abrauchen, ohne dass ich zwischenzeitlich Ersatz bekomme. Damit kann ich leben.
P.S. Dass das jetzt alles OT ist, ist für mich völlig in Ordnung. Meine Ursprungsfragen hat man mir ja vollständig beantwortet.
-
vor 8 Stunden schrieb NilsK:
Moin,
als "unzulässig" könnte Microsoft es nur bezeichnen, wenn es gegen Lizenzbestimmungen verstößt. "Nicht supported" bedeutet: wenn "sowas" gemacht wird, leistet der Hersteller keine Unterstützung dafür - typischerweise weder für Probleme, die direkt aus "sowas" entstehen (hier etwa: die Replikation funktioniert nicht), meist aber ausgedehnt auf jede Art von Problem, auch wenn sie nur sehr indirekt mit "sowas" zu tun hat (Beispiel: der Mailversand klappt nicht).
Wenn man Lust hat, "sowas" dann selbst zu supporten, hält einen Microsoft nicht davon ab. Nur kann man dann eben nicht bei Microsoft anrufen, wenn was klemmt (um vorzubeugen: doch, kann man schon, die werden aber sehr bald das Gespräch beenden). Da ein solcher Zustand für die meisten Unternehmen indiskutabel ist, kommt "nicht supported" schon nah an "unzulässig" heran.
Gruß, Nils
Eine Lösung wie die Hyper-V-Replication von Exchange wird Microsoft wohl schon deshalb nicht supporten, weil es für Microsoft total uninteressant ist. Interessant ist das nur für kleinere Umgebungen, die Microsoft ohnehin in die Cloud schieben möchte. Größere Umgebungen sollen das über DAG lösen, was ja sicherlich auch besser ist als Hyper-V-Replication. Jede kleinere Umgebung, die alles On-Premises lösen will, muss gucken, zu welchen Kompromissen man bereit ist. Da kann es manchmal erwägenswert sein, auch einen Weg zu gehen, bei dem es keinen Support von MS gibt.
Übrigens an alle ein herzliches Dankeschön für die Beiträge hier! Die Hyper-V-Server habe ich jetzt auf Windows Server 2019 umgestellt, da die Lizenzen ohnehin da waren. Ich hatte etwas Bedenken, WS 2019 auf recht betagter Hardware zu installieren (sechs Jahre alt). Gefühlt war die Installation von WS 2019 aber sehr unproblematisch und problemloser als die vieler anderer früherer WS-Versionen. Und die Updates laufen plötzlich ziemlich schnell.
-
vor 21 Stunden schrieb MurdocX:
Hallo,
deine Aussage ist technisch nicht richtig, deshalb auch nicht deine Schlussfolgerung. Ich zitiere von Microsoft: https://docs.microsoft.com/de-de/exchange/plan-and-deploy/virtualization?view=exchserver-2019
Snapshots (Checkpoints) sind nicht "Application Aware". Die Windows Server Sicherung aber schon. Das ist ein großer unterschied
Daraus resultiert die Möglichkeit eines Datenverlustes und das erklärt auch warum Microsoft das nicht unterstützt. ok und Danke für die Info. In irgendeinem Blog hatte ich mal gelesen, dass das mit der Replikation von Exchange in Hyper-V klappen kann, seit es Production-Checkpoints gibt. Zur Nachahmung war es aber sowieso nicht empfohlen.
-
vor 43 Minuten schrieb testperson:
Klingt jetzt aber doch so, als wäre ein dritter Host angesagt.
Meistens fallen halt die Dinge, die ausgeschaltet bleiben können / unwichtig sind, genau dann aus, wenn sie ganz ganz dringend benötigt werden. ;)
In den meisten Fällen dürftest Du damit Recht haben. Das Ausfallen eines physischen Hosts wäre bei uns dadurch zu kompensieren, dass im Wesentlichen nur die VMs, die für den Remotezugriff "zuständig" sind, ausgeschaltet bleiben. Das ist bei uns nicht systemkritisch und hat nur für wenige User Folgen. Das könnten wir tatsächlich verschmerzen.
-
vor 6 Minuten schrieb Dukel:
Auch bei Hyper-V Replica kann man die Maschinen verschieben. Bei der manuellen Tätigkeit gibt es keinen Datenverlust.
Das ist übrigends keine Hochvefügbarkeit, das ist eine DR Lösung!
Stimmt, das ist keine Hochverfügbarkeit. Es ist aber eine gute Fallback-Option, mit der ich seit Jahren gute Erfahrungen mache.
vor 4 Minuten schrieb Nobbyaushb:OT on - nicht für alles ist Replica zulässig! AD nein, Exchange nein, SQL unter bestimmten Voraussetzungen - OT off
Stimmt. Da man für die Replikation ohnehin doppelte Lizenzen braucht, habe ich auf jedem Host einen DC (mit AD und DNS), die ohnehin aufeinander replizieren. Zum Exchange habe ich backups und eine separate Maschine mit Mailstore. (Stimmt, ist jetzt aber echt OT).
Übrigens: Für Exchange ist Hyper-V-Replication nicht "unzulässig", es ist "nicht supportet". Das heißt nicht, dass es nicht funktioniert (und technisch müsste es es funktionieren, jedenfalls, seit Production-Checkpoints repliziert werden, das habe ich aber noch nicht probiert. Windows-Server-Backup sichert den Exchange auch nicht anders, und das funktioniert nun nachweislich gut.).
-
vor 1 Minute schrieb Sunny61:
Was spricht gegen die Erstellung eines Clusters? Dann das ganze per PS-Script. Wartungsmodus einschalten, Maschinen werden verschoben, anschließend die WUA_SearchDownloadInstall.vbs passend aufrufen, schon wird automatisch gedownloadet, installiert und gebootet. Am nächsten Tag dann den zweiten Node aktualisieren.
Und wenn die beiden Hosts wirklich das Rückgrat sind, solltest Du dir in Sachen Ausfallsicherheit etwas überlegen. Sind die Hosts mit den vorhandenen VMs denn ausgelastet oder kann 1 Host alle VMs hosten?
Nett wie bei solch einfachen Fragen zu WU dann solche Konfigurationen zu Tage kommen.
Die beiden physischen Hosts sind hardwaretechnisch fast identisch. Ausfallsicherheit besteht durch Hyper-V-Replication, mit der die wichtigsten Server-VMs jeweils auf den anderen Host repliziert werden. Wenn ein physischer Host ausfällt, müssten ein paar VMs "ausgeschaltet" werden, die zentralen Dingen laufen dann aber dann auf dem verbleibenden Host weiter (DC, AD, Printserver, Exchange, Fileserver). Klappt bislang alles so ganz gut, immerhin seit ca. 6 Jahren ohne größere Probleme. Ist mehr so Hochverfügbarkeit und Clustern für Arme, angesichts der geringen Größe des Netzwerks aber akzeptabel.
-
vor 16 Minuten schrieb NorbertFe:
Es geht aber um Updateverhalten von Windows 2016 und nicht um pragmatische Lösungen. :P
Entschuldige, so war das nicht gemeint. ;)
-
vor 3 Minuten schrieb testperson:
Hi,
Da hast du doch schon gemerkt, dass das teils ziemlich dürftig ist.
Ich verstehe aber auch so wirklich das Problem nicht:
Host1 -> Wartungsmodus an -> Update (auch wenn es x Stunden dauert) -> Reboot (ggfs. nochmals Updaten) -> Wartungsmodus aus -> "Test" -> "zurück in Produktion" -> "Warten" -> Mit Host2 vorne anfangen.
Wenn euch die Zeit ohne Redundanz zu lange ist, dann muss eben ein Host3 her.
Gruß
Jan
Vielleicht ist das aus Deiner Sicht kein Problem. Es dauert aber stundenlang. Das nervt, deswegen habe ich hier einmal in die Runde gefragt. Mit WS 2019 ist das Ganze vielleicht in 30 Minuten erledigt. Das ist dann ein Vorteil. Darum geht es mir, ob ein Upgrade der Hosts sinnvoll ist. Jetzt einen dritten Host anzuschaffen, wäre angesichts der Größe unseres Netzwerks übertrieben (und ist hier auch ziemlich OT).
-
Gerade eben schrieb NorbertFe:
Wenn das so kritisch ist, sollte man eben über Redundanzen oder entsprechende Downtimes reden.
Das mag sein. Mir geht es hier um das Update-Verhalten von WS 2016.
-
vor 5 Minuten schrieb Sunny61:
Wir haben ein GPO das die Updates um 3 Uhr in der Nacht installiert. Die Server werden tagsüber in eine Gruppe auf dem WSUS verschoben, für die die Updates zur Installation freigegeben sind. In 99% der Fälle funktioniert das Installieren der Updates auch auf W2016 damit problemlos. Wenn ihr Hyper-V Hosts im Cluster habt funktioniert die Vorgehensweise mit der Installation in der Nacht AFAIK ebenfalls.
Wir haben zwei Hyper-V-Hosts, die sind sozusagen das Rückgrat der gesamten IT. Die würde ich nur ungern unbeaufsichtigt nachts updaten und neustarten.
-
Hallo an alle,
das Update-Verhalten von Windows Server 2016 erlebe ich als fast schon unerträglich. Allein der Download der monatlichen Updates dauert (nach Anzeige) über eine halbe Stunde, dazu kommen (gefühlt) ewige Installations- und Neustartzeiten. Das Thema ist auch schon an einigen Stellen thematisiert worden, zB
Hinzu kommt bei mir noch das folgende Phänomen: Wenn das quälend langsame monatliche Update eingespielt ist (im Juli etwa KB4507460), dann fordert WS 2016 direkt noch einmal die Installation weiterer Updates (im Juli etwa (KB4507459). Fast jeden Monat das gleiche. Resultat ist wieder die gleiche, ewig lange Prozedur. Das nervt extrem.
Weiß jemand,
- ob es hierzu bald von Microsoft eine Lösung gibt?
- ob ich etwas falsch mache?
- ob insbesondere der doppelte Update-Aufwand durch zwei Kumulative Updates im Monat vermeidbar ist?
Nerven tut dies natürlich insbesondere auf den Hyper-V-hosts. Hat jemand Erfahrung mit WS 2019 als Hyper-V-Host? Ist es dort besser?
Danke für jede Hilfe! -- Gruß, Horstenberg
Volltextsuche über Netzlaufwerke: wie löst Ihr das?
in Windows Server Forum
Geschrieben
Copernic Desktop Search haben wir bis vor einigen Jahren auch in unserem Netzwerk gesucht. Es war in vielerlei Hinsicht unzuverlässig. Wir haben sicher drei Versionen abgewartet, es hat aber nie zufriedenstellend funktioniert.
Wir versuchen uns jetzt mit Lookeen in der Enterprise-Version. Das Zuschneiden auf unser System erweist sich als aufwändig. Es funktioniert bei uns aber besser als Copernic.