Weingeist

Hallo Leute, Nach ersten Tests (wurde leider geschlossen) habe ich die Tests noch etwas weitergeführt. Imho sind die Ergebniss ein Beitrag wert. Jeder der Software-RAID per se als Schrott ansieht, soll sich doch diesmal raushalten und jene Profis antworten lassen die StorageSpaces schon auf Herz und Nieren geprüft haben. Hätte gerne ein paar Inputs. :) --> Es kann nicht komplett unbrauchbar sein, wenn einige grosse Hersteller Cluster-In-A-Box Lösungen in der Pipeline haben mit genau dieser Funktionalität. Kurzes Fazit nach den Tests, es ist extrem schwierig ReFs und Mirrored-Volumes wirklich kaputt zu kriegen. Folgender Testaufbau: - Server 2012 als VM in ESXi - virtuelle SAS Festplatten - Windows XP als Manipulator (2012 verhindert ein Direktbeschrieb der Disks) Adminrechte reichen unter 2012 nicht aus die Discs manuell mit einem Tool zu manipulieren. HyperV erlaubt leider nicht die gemeinsame Verwendung von virtuellen Discs, deshalb ESXi. Vorgenommene Manipulationen: Manipulation von einzelnen oder ganzen Sektorbereichen mit Windows XP. Entfernen von HDD's etc. Wie reagiert Windows: - Solange ein Mirror-Partner korrekte Daten liefert öffnet Windows die Datei. - Manipuliert man alle Mirror-Partner ist die Datei korrekt lesbar, solange sie auch im RAM-Read-Cache ist. Nach einem Neustart gibt es eine Fehlermeldung. - Ein ändern/speichern der Datei korrigiert automatisch alle Mirror-Partner indem das File in einen neuen Sektorenbereich geschrieben wird. Die Gretchenfrage: Wie bekommt man nun die Daten auf den anderen Datenträger wieder korrigiert? Dazu muss man einen Integritätscheck anstossen können. Die Powershell-Storage-Cmdlets führen aber nicht wirklich zu einem Ziel. Dateisystem nicht unterstützt. Sehr hilfreich. Sucht man nun im Netz, stösst man nur auf die Integrity.exe. Die gibt es aber gar nicht (evtl. in ner Beta?) und findet man auch nicht als Download. Selbst MS hat sie aber in einer Technet-info vermerkt. Die Fehler waren auf den Mirror-Partner nach einem harten ausschalten der VM plötzlich korrigert. Also musste es was geben. So ist es auch: Aufgabenplanung>Microsoft>Windows>Data Integrity Scan Diese verweisen nicht etwa auf eine versteckte Integrity.exe, sondern auf eine DLL: DiScan.dll Stösst man diesen Job manuell an, werden die Daten sofort korrigiert. Mit SSD's klappt das auch mit grossen Files und vielen Fehlern extremst schnell. Der übliche Intervall (ohne Crash) ist mit 4 Wochen sehr hoch angesetzt. Kann und sollte man imho tiefer setzen. Auch mit diesem Wissen findet man zu diesem Job aber irgendwie nix ausser in diesem Dokument Da wird aber beschrieben, dass man Files ausschliessen kann. Fazit: Bin ziemlich überrascht wie gut und stabil das funktioniert. Mit ein paar SSD's bekommt man ein extrem performantes, ausfallsicheres sogar Trim-Unterstütztes sehr flexibles Storage mit Standardhardware. Imho eine sehr gute und kostengünstige Lösung für Kleinumgebungen. Es gibt einige Unahmlichkeiten die man halt lösen muss. Ist aber beherrschbar. - Fehlermeldungen sind zbsp. So la la, nur Totalausfall eines Volumes gibt sichtbare Warnung, sonst nur ein Ereignis. Kann man aber Triggern und sich benachrichtigen lassen: Kann dazu diesen Beitrag empfehlen. - Erkennen des richtigen Schachts wo die Disc ist (Auf SES Unterstützung der Hardware achten > HD markierbar), SCSI-ID ist NICHT Reihenfolge in Windows.

Sobald man den SBS inklusive Exchange betreibt würde ich mir ernsthaft Gedanken um eine sinnvolle Near-Continues-Datensicherung und/oder Replikat machen. Auch wenn das alles doll revisionssicher abgelegt ist, ist es so bequem wie Exchange oder bringt das viel Nacharbeit mit sich die Mails wieder in Exchange zu kriegen? Bis und mit 2003 habe ich einem SBS auch keinen zweiten DC hingestellt, weil DC-Leichen aus dem AD entfernen eine mühsame Angelegenheit waren (Abschalten ZweitDC vor einhängen des SBS ins LAN und Entfernugn des ZweitDC aus AD weil Rückspielung des SBS von einem Image einen alten AD-Stand bedeutet). Ab 2008 geht das ziemlich schmerzfrei, sollte es mal notwendig sein. Als Alternative bietet sich wie gesagt eine gute, datenbankkonsistente Replikationslösung an. Mit HyperV habe ich da noch keinerlei Erfahrung. Finde ich bei nem SBS etwas zweischneidig, zumindest wenn HypverV im AD drinn ist. Schaltest das Replikat des SBS hoch, hat dieses AD einen älteren Stand als dein ZweitDC. Ohne deinen ZweitDC steht aber vielleicht deine HyperV-Umgebung (muss jemand beantworten der sich damit auskennt). Solche Lösungen gibt es auch mit Auto-Failover (Beachten: Split Brain). Ich bevorzuge manuelle Umschaltung. Ansonsten: Als Pop-Alternative für Kleinbetriebe und Dynamic IP (wens nix anderes zu Vernünftigen Konditionen gibt) kannst Dir eventuell auch DynDNS Gateway anschauen. Update der IP bei DynDNS via Router. Hat ein sehr kleines Zeitfenster wo man nicht erreichbar ist. Das Risiko dass sie jemand anders bekommt und Deine Mails abfängt ist ziemlich klein. Ist dein Server nicht erreichbar, werden die Mails zwischengespeichert und erst weitergeleitet wenn er wieder erreichbar ist.

Nicht überall sind die Anforderungen an die Verfügbarkeit gleich gross. Die Priorität liegen in Mini-Umgebungen meist bei: - Einfache Umgebung - Im Desasterfall kleiner bis kein Datenverlust - Komfort einer Serverumgebung für Zugriffsrechte Bei Singleserver mit AD ist es total schnuppe wenn das AD einen etwas älteren Stand hat. Zumindest solange kein Exchange mit von Partie ist wo aktuelle Mails gefragt sind. Dieser ist dann aber eh nicht zu empfehlen. Vorschlag: - Sicherung von Files mit Robocopy-Scripts -- zbsp. Mirror ohne Files zu löschen / Fullbackups mit Datum als Ordnerstruktur (20121024 oder so) und direkter anschliessender komprimierung mir RAR, verteilung auf weitere Rechner usw. - Full-Backups auf eine zweite interne Festplatte (evtl. Explizit File-Ordner davon ausnehmen = schneller wiederhergestellt) - Dazu ab und wann ein Image mit zbsp. Acronis Universal-Restore (evtl. ohne Nutzdaten) --> Tendenziell einfachere Wiederherstellung auf neuem Server. Ist alles extrem billig, wirkungsvoll und die Umgebung ist trotzdem in nützlicher Frist wieder oben. Datenverlust hält sich ebenfalls sehr in Grenzen wenn man das Script für den FileMirror mehrmals täglich ausführt (Sehr schnell durch in Kleinumgebungen). Dazu eine Checkliste an der Tür wo man die Überprüfung der Backups signieren muss sowie eine ausführliche Dokumentation wie das Ganze aufgebaut, unterhalten und aufgeräumt wird. Mag zwar nicht dem Anspruch absoluter Professinalität erfüllen und klingt mehr nach Bastelei, aber es erfüllt den Zweck für Kleinstumgebungen. Als Backupziel können für die Scripts zbsp. Partitionen auf den meist übergrossen Festplatten der Clients auf welche nur ein spezieller BackupUser Zugriff hat (Script unter diesem Namen als Task ausführen). Kann man auch wunderbar auf mehrere verteilen. Sehr oft ist das deutlichst schneller und besser beherrschbar als mit den Billig-NAS-Teilen und Rechtevergabe bleibt erhalten. --> Sollte alles schief gehen, bekommt man mit dem lokalen Admin trotzdem Zugriff auf die Dateien.

Der SBS verträgt sich eigentlich mit allen. Er ist nur nicht sehr erfreut ist, wenn man ihm die Chefrollen über ADS wegnimmt oder einen zweiten SBS zur Gewaltenteilung hinstellt. ;) --> das heisst er will die FSMO Rollen innehaben sowie die AD-Struktur muss auf seiner Ebene liegen. Also nicht AD auf 2012 hochstufen. Was mir an deinem Konzept fehlt: - Zweiter DC fals dein SBS mal Schluckauf bekommt - Ist der SBS nicht wichtig genug für eine Replica? Mails zbsp.

Hast Du nie Probleme sobald er die Verbindung mal hatte? Ein Schuss ins Blaue: Ich hatte mal die ähnliche Sympthome - bis auf die schwarzen Bildschirme - und mit XP. Immer auf den gleichen Clients probleme mit den Shares, DNS, Anmeldevorgang etc. Während der Arbeit dann nicht mehr bemerkbar. Die Problematik lag da weniger an der Software sondern an der Infrastruktur. Einige Leitungen waren schlicht nicht gut genug für Gbit, da beim einziehen zu stark gezogen wurde. Habe dann erfahren, dass es Mühsam war sie durch die Leerrohre zu kriegen, doll. Bei manchen kamen die Probleme schleichend und wurden schlimmer. Bei einigen waren sie vom Server plötzlich nicht mehr als sicher anerkannt und wurden abgekoppelt. Kannst du einfach testen indem du einen 100er Switch dazwischen hängst. Nachher auf dem MainSwitch den Port manuell drosseln sollte es klappen. Ein andermal lag es an der Schirmung die irgendwo unterwegs einen Knacks haben musste. Auf alle Fälle klappte es an diesem Client nur mit einem ungeschirmten Kabel. Seither keinerlei Probleme mehr. Da gab es allerdings richtige und sichtbare Netzwerk-Disconnects.

Refill (Nicht-Original-Toner) hatte ich nur lausige Erfahrungen gemacht - Nach 1/3 bis 2/3 der Füllung war die Transferrolle in der Regel hinüber - Kein sauberer Übertrag mehr oder Striemen - Einer hat mir mal den ganzen Drucker eingesaut, war eine schöne Schweinerei. Gibt aber auch Nicht-Originale von Profis, die sind angeblich genauso gut, da sie die Verschleissteile ersetzen? Mir hat obiges gereicht. Kauf einfach ne grössere Menge bei Aktionen, die sind nicht wahnsinnig teuer. Betreffend Miete: Kommt immer drauf an wie man rechnet. Ich fand es rentiert sich nicht. Zumindest wenn man die 'richtigen' Gerätepreise nimmt. Nicht von einem Vermieter. Ab einer gewissen Anzahl ist das Risiko zudem verteilt. Da sollte günstiger sein mal einen externen Techniker selber zu bezahlen. Innerhalb der Garantiezeit kostet der externe Techniker nix. Nachher kann der Betriebswart/Unterhaltsmensch/Mechaniker/Technisch begabt MA die Geräte i.d.R. auch selber warten. Viel drann ist ja selbst bei den grossen nicht. Wird ja heute eh meist getauscht und nicht repariert. ServiceManual + Service-Softwareerhalt an den Kauf binden (bei grösseren Geräten). Hinzu kommt, dass die Jungs die Geräte oft nach wenigen Jahren wieder tauschen wollen, dann kann man unter Umständen wieder alle Automatisierungen neu programmieren, Treiber neu ausrollen usw. Ansonsten hat man sie vielleicht deutlich länger im Einsatz. Wie zbsp. die praktisch untödlichen 4050er HP. Mit minimalen laufenden Kosten ein gutes SW-Druckergebnis und die Dinger sind schon über 10 Jahre alt. Reparaturen total easy. Bei nem Farblaser für Broschürendruck hab ich auch nix dagegen aber sonst? Steuervorteil schwer zu sagen, ausser man schaut höhere Ausgaben auch als Steuervorteil an :D Ist das Volumen ausreichend gross, kann man das ganze über ein Industrieleasing abwickeln und die Geräte sind zbsp. nach drei Jahren komplett abgeschrieben (CH). Der Wiederverkaufswert ist nicht massgeblich billiger als der Gerätewert zum Auslauf des Vertrages, daher kein Problem. Geht auch für Spezialanfertigungen usw. die der Markt nicht wirklich braucht und somit Wiederverkaufswert im Verhältniss zur Investition nach diesen Jahren eher tief ist (Kernkriterium, damit diese Art von Beschaffung/Abschreibung erlaubt ist). Natürlich nur brauchbar, wenn die Firma auch genügend solvent ist und immer wieder Investitionen hat. Wenn man das alles miteinbezieht geht die Rechnung mit sehr grosser Wahrscheinlichkeit immer gegen den Dienstleister. Ist ja auch logisch, es ist einer mehr der Geld verdienen will. ;)

OK, ich war nicht genug ausführlich. Ich finde es macht Sinn den Backup-Speicher nicht im üblichen LAN Netz sondern über eine eigene Nic bzw. deren zwei anzubinden. Mehr als eine NIC ist im SBS aber nicht supported. Via einem Hypervisor umgeht man das einfach. So siehts aus, das meinte ich mit weniger bequem. Man muss sich etwas überlegen für die Wiederherstellung und dementsprechend vorsorgen. Verwendet man einen Hypervisor ist dieses Problem auch einfach umschifft. Wie gesagt, es gibt mehrere Wege nach Rom. Für mich hat es sich bewährt die Komplexität weg von einem SBS zu nehmen und im Hypervisor abzubilden und am SBS selber möglichst nichts zusätzliches aufzubürden/spezielle Konfigs vorzunehmen. Dazu stabile Hardware und redundante Komponenten/Anbindung. So erspare ich mir Ärger, Zeit und Geld, bei verhältnissmässig kleinen Investitionskosten. Zudem ist die Umgebung schnell wieder oben und der Datenverlust minimal. Kann man natürlich noch mit einer Replikationslösung ergänzen, zbsp. DoubleTake (evtl. neu auch mit Hyper-V, noch nicht ausführlich Disaster-Szenarien getestet), wenn die Ansprüche an Datenverlust und noch schnellere Verfügbarkeit höher sind, ohne eine grosse komplexe Infrastruktur und teure SAN zu brauchen.

Mein Beitrag gar nicht gesendet am Samstag... Oops. @MrCocktail: Sage ich doch gar nicht. Klingt doch gut. Auch ich verwende jeweils die interne Sicherung und verschiedene Ziele, hat sich gut bewährt. Der TO hat nicht klar gesagt was sein Konzept ist und die einzelne Platte kling schwer nach einzelne Platte für die Sicherung :) Vielleicht als Ergänzung oder Alternative: - SBS virtualisieren - Backupplatte (am besten deren zwei, als Spiegel) in ein kleines NAS in einem anderen Gebäude/Brandabschnitt/Raum - die Platten per iSCSI dem Hypervisor zu Verfügung stellen (dedizierte LeitungEn, direkt verbunden) - auf den Platten virtuelle Discs erstellen und dem SBS zuweisen auf welche er sichern kann (werden als interne Discs gesehen = Inkrementelle Backups möglich) - regelmässig die virtuellen Sicherungs-Discs wegkopieren/sichern auf USB, Netzwerkshares usw. Auf USB kann man mit simplen Scripts das ganze für den Chef automatisieren. Dazu ne Liste an die Tür pinnen wo er unterschreiben muss, dass ers auch tatsächlich gemacht hat ;) Dies hat folgende Vorteile: - USB-Backups werden erfahrungsgemäss zu selten gemacht, so hast immerhin etwas das immer gemacht wird, auch wenn Du nicht da bist - Du hast konstante, ältere Backuparchive wenn Dir die Hauptarchive aus welchem Grund auch immer zerschossen werden, sei es nur aus Fahrlässigkeit - Du kannst eine Kopie einer solchen VHD risikolos in eine andere VM einbinden und Backups auslesen/Recovery durchführen ohne jeden Einfluss auf das Original --> Überprüfung - Der SBS ist als VM portabel und kann einfach in Testumgebungen kopiert werden um upgrades auszutesten oder beim Crash des Servers einfach auf einem neuen hochgezogen werden - Es ist supported Das erleichtert einem imho die Arbeit mit SBS-Server und die Nachteile der Diva lassen sich ziemlich gut umschiffen bzw. das Verhalten von Änderungen, Updates etc. erst austesten und im Notfall hat man sichere Backups die sehr schnell verfügbar sind. Gibt auch noch die Möglichkeit per iSCSI Festplatten an einen physischen SBS anzubinden. Gibt aber evtl. Nachteile für die Wiederherstellung (nicht der gleiche Komfort) und es ist unsupported. Das Risiko -unsupported - ist imho zwar meiner Meinung nach gut beherrschbar indem bei jeder Verwendung der Assistenten die Adapter deaktiviert werden, aber es bleibt eben unsupported. Im Fehlerfall muss man vielleicht den Fehler auf einer anderen Maschine reproduzieren können, damit MS hilft. Könnte auch sein, dass sie nicht helfen wollen.

Das Problem ist wohl vielleicht auch, dass Du in den Einstellungen nicht manuell auf UEFI-Boot geschalten hast. Standardmässig steht da BIOS-Boot drinn. Lässt sich wunderbar installieren, aber nicht starten. ;) EDIT: Findet sich unter Einstellungen der VM>Optionen>Startoptionen

Zu deiner Frage: Wie bereits von anderen gesagt es geht so nicht. Gibt aber durchaus andere Variante wo Du sie trotzdem einsetzten kannst. Ansonsten: Man kann jetzt zwar nicht direkt herauslesen ob das Deine übliche und einzige Sicherung ist oder nicht aber fals ja (leider oft der Fall in SBS-Umgebungen) würde ich mir das Backupkonzept überdenken. Es gibt imho nur wenige sinnvolle Möglichkeiten eine SBS-Umgebung mit Boardmitteln zuverlässig, automatisch und regelmässig zu sichern und auch vernünftige Wiederherstellungsoptionen zu haben ohne das der User sich grossartig auskennen muss. Fals Interesse besteht kann ich gerne etwas dazu schreiben.

Die Grenze ist etwas schwammig wie ich finde und bietet im Gegensatz zu anderen Definitionen doch etwas Auslegungsspielraum. Bei einem reinen Backupziel dürfte man es wohl. Weil MS auch Fremdanbieter gleich lange Spiesse bieten muss, ist das meiner Meinung nach etwas graue oder gar dunkelgraue Zone. Kurz absichern bei MS mit dem geplanten Aufbau und dem genauen Zweck würde ich dennoch, nur schon um allfällige Diskussionen zu vermeiden. Aber unabhängig davon bin ich der Meinung, dass eine Desaster-Lösung konsequent in ein anderes Gebäude/Brandabschnitt/Raum gehört und in keinem Fall auf die Produktivserver.

@Blazilla: Klar. Klingt alles gut. Was Strom leitet, kann auch kaputt gehen. Deshalb bleibt eine einzelne SAN nunmal ein SPOF. Kann man drehen und wenden wie man will. RPO wird bei deren Ausfall kaum erreicht. Wird das nicht kommuniziert, belügt man den Kunden oder muss ein entsprechendes Backup-Storage im Köcher haben (woran man in der Regel sparen muss). Am Rande: Ein Ausfall der Main-Backplane wo die RAID-Controller drauf sitzen verkraften die wenigsten. Auch Zusatz-Shelfs sterben nicht immer sauber weg. Ein Kleinbetrieb kauft zudem selten die Middle- oder Topausführung der Hersteller oder gar gespiegelte Storages. Solche mit Transparentem Failover schon gar nicht. Neben den Investitionskosten sind auch die Wartungskosten hoch. Mir sind daher Server die gegenseitig repliziert werden lieber. Das ist immer Ruckzuck, mit konsistenten DB's wieder oben wenn mal was in die Hose geht. Ohne grossen Aufwand und Komplexität. Je nach Lösung und Datenaufkommen quasi ohne Datenverlust. Bevor mir wieder das Wort im Mund umgedreht wird: Kleinumgebungen mit ein paar Server. Um zum eigentlichen Thema zurück zu kommen: @dieDally: - Bei 80 Desktops eine VDI oder quasi VDI betreiben wenn die Lizenzkosten für RDP schon gescheut werden ist schwierig. Grund: Du kannst sicher keine OEM-Office verwenden sondern brauchst Volumenlizenzen. Office OEM auf konsoldierten System ist ein Lizenzverstoss (ausser Office bis 2003). - Desktops zwischen Hosts verschieben geht nur mit SA oder VDA. Bei beidem bist Du verpflichtet jährlich zu bezahlen damit es geht. Keine Auskaufmöglichkeit. Aktuell besteht aber die Möglichkeit mehrere Lizenzen einem System zuzuweisen. - Du willst auch Linked Clones oder etwas ähnliches. --> Masterimages, das kostet wieder Geld (View, Citrix, ...) sonst ist ein grosser Verwaltungsvorteil weg. (Wobei: HyperV 3 hat dafür auch was neues im Köcher, keine Ahnung wie gut das funktioniert und was es noch braucht) - Bricht dein Storage weg (auch wenn selten), dann hast Du je nach Schaden ein massives Erklärungsproblem wenn du dem Chef zuvor eine teure SAN verkauft hast mit der Begründung, dass eben Ausfälle nur von kurzer Dauer sind und das Geld nicht für ein einigermassen performantes Notsystem reicht. Da hilft es herzlich wenig wenn es normalerweise nicht passiert. Bei der Betrachtung der reinen Lizenkosten wirst die Schlacht aber sowieso verlieren und die RDP-Lizenzen erscheinen im Gesamtkonzept geradezu günstig. Zentrale Verwaltung und gute Anbindung hättest auch mit physischen Maschinen im Serverraum. Deployment und Wartung aufwendiger aber auch vereinfachbar. Günstig wärs mit zbsp. Atom-PC's (soferne ausreichend). Geht dann je nach Konzept wieder mit OEM-Software. Möglichkeiten gibts hier auch einige die einen sinnvoll die anderen weniger, von physisch normal über einer VM pro Maschine, Wartung und Deployment bia IPMI usw. Hast Du viele gleiche Desktops, fährst Du aber vermutlich besser und einfacher mit TS. Wie du siehst, es gibt nix umsonst was das Admin-Leben vereinfacht und die RDP-Lizenzen sind mit Abstand der kleinste Posten. Ich bin happy wenn ich via RDP durchkomme anstelle von VDA. ;)

Wie bereits gesagt, das geschieht, wenn Du auf einem SBS 2008 die WSUS Rolle aktualisierst. Da wird standardmässig eine veraltete installiert, 2008 ist ja schon ein paar Jahre alt. Dazu wird der alte WSUS normalerweise deinstalliert. Die alte Seite auf dem ISS bleibt aber erhalten. Allgemein zum SBS: Man weiss nie so richtig, was genau miteinander verhängt wurde oder was von Update-Rollups speziell für SBS für ein Zustand erwartet wird. Manchmal schlugen die Updates in der Vergangenheit (Pre 2008) wegen banalen Veränderungen fehl. Deshalb halte ich mich - nach einigen leidigen Erfahrungen unter NT, 2003 - generell an die Devise: Nichts am Standardverhalten des SBS ändern oder löschen was nicht zwingend nötig ist oder in einer HowTo von MS beschrieben worden ist. Und wenn, sehr sauber dokumentieren, damit man es für Updates rückgängig machen könnte. Erspart einem unter Umständen sehr viel Ärger. Glaube zwar ehrlich gesagt auch nicht, dass das löschen einen Einfluss hat, aber stören tut die deaktivierte Seite auch nicht. ;) Bei einem Update von SBS auf einen neuen Server und eine aktuelle Version ist das nicht von Belang, da ja der Server neu installiert wird. InPlace Update gibt es sowieso nicht.

@StefanWe: Die Backplane einer SAN ist auch eine Elektronisches Teil und kann im Prinzip genauso kaputt gehen wie jedes andere Elektronik-Teil auch. Die gibts nur einmal. ;) Nichts desto trotz mit einem Shared Storage hat man es von der Verwaltbarkeit einfacher. Wenn man aber nur eine hat, muss bei einem Ausfall unter Umständen ne Menge repariert oder frisch aufgesetzt werden. Alternative: Du nimmst local Storage und replizierst jeweils auf einen anderen Server. Stirbt einer weg, kannst die Replikate nehmen. Klappt mit Veaam zbsp. gut unter VmWare. Das neueste Hyper V kann aber auch selbständig replizieren. Wie gut und zuverlässig kann ich nicht sagen.

Das geschieht - soweit ich mich richtig erinnere - wenn der WSUS upgedated wurde. Sprich hast du einen etwäs älteren SBS und nachher ServicePacks und das neuere WSUS eingespielt, dann erstellt er Dir die Administrations-Seite. Ich hatte jeweils einfach die Seite "WSUS-Verwaltung deaktiviert". Unter Einstellungen Autostart zusätzlich auf False stellen. Ports musste man glaub keine mehr ändern, bin ich aber nicht mehr 100% sicher.

@Zahni: Wartung: Logisch, hier können aber Third-Party Erweiterungen wie es auch sonst für Windows gibt hinzukommen. Dafür gibt es API's, Schnittstellen und dergleichen. Für kleine und mittlere Umgebung reicht Benachrichtigung und auto Hotspare-verwendung völlig aus. Zu High-Performance: Schau dir mal die neuen Scale-Out-Features aus. Da sind nur die IOPS des Datenträgersystem die Limitierung. Ansonsten geschehen Reads über alle ClusterNodes gemeinsam. Quasi Out Of the Box. Aktuell extra für VHD's und SQL-Datenbanken. Zu den Pools: Da Windows es total egal ist wie gross die Platten sind, kann man einfach alles reinhängen was 'rumsteht'. Der Rest erledigt es selber aufgrund der Definition welche man für die virtuellen Datenträger angegeben hat. Die jeweiligen Platten sucht er sich selber aus. Es steht einem natürlich nichts im Wege - sofern man Windows nicht richtig traut oder als zusätzliche Sicherheit - erstmal RAID-Volumes als Basis für den Aufbau zu nehmen. Und noch eine gute Nachricht: Bei Pools funktioniert Trim trotzdem! sowohl mit NTFS als auch mit dem neuen. Habe da einen kleinen Fehler gemacht (leicht zu kleines Files für den Trim-Test verwendet). Zum ZFS: Das ist eigentlich richtig nett. In der höchsten Ausbaustufe, die allerdings auch nicht günstig zu haben ist, sogar mit transparentem Failover über mehrere Nodes. Dazu extrem gutes Dedup, übelste Performance (trotz verwendung von SATA Platten, weil Read und WriteCaching machbar, sowohl mit SSD's als auch mit RAM). Da kannst zbsp. auch pro Block jeweils Doppel, Dreier, Viererpakete von HDD's oder soviel Du willst machen. Die DiskBlocks hängst dann zusammen. Speichererweiterung in dem du einfach einen identischen Block wieder dazufügst. Windows geht da aber weiter, da hängst einfach Platten rein und definierst in der virtuellen HD, was für Voraussetzungen sie erfüllen muss. Entweder mit JPOD's auf welche mehrere Server gemeinsam Zugriff haben oder eben auch direkt mit lokalen Discs oder iSCSI/FC Zielen. @ChristianZ: Die HostCPU muss Paritäten berechnen, das braucht sicher etwas mehr Leistung als Mirror-Lösungen. Da habe ich noch keine Tests gefahren, ist aber auch nicht meine Priorität. Ich verwende "nur" Mehrfachspiegel. Aber wie gesagt, bei den Leistungen welche heutige CPU's bringen, zusammen mit dem RAM-Cache, ich glaube da muss sich Windows den wenigsten Einsteiger oder Mittel SAN's geschlagen geben in Sachen Performance und mit den neuen Features sicher auch in Sachen Flexibilität. Ich kann von den IOPS-Werten in meinem TestLab auf meiner (für meine Verhältnisse) teuren SAN mit minimalen Features nur Träumen. ;)

@Zahni: Wartung: Logisch, hier können aber Third-Party Erweiterungen wie es auch sonst für Windows gibt hinzukommen. Dafür gibt es API's, Schnittstellen und dergleichen. Für kleine und mittlere Umgebung reicht Benachrichtigung und auto Hotspare-verwendung völlig aus. Zu High-Performance: Schau dir mal die neuen Scale-Out-Features aus. Da sind nur die IOPS des Datenträgersystem die Limitierung. Ansonsten geschehen Reads über alle ClusterNodes gemeinsam. Quasi Out Of the Box. Aktuell extra für VHD's und SQL-Datenbanken. Zu den Pools: Da Windows es total egal ist wie gross die Platten sind, kann man einfach alles reinhängen was 'rumsteht'. Der Rest erledigt es selber aufgrund der Definition welche man für die virtuellen Datenträger angegeben hat. Die jeweiligen Platten sucht er sich selber aus. Es steht einem natürlich nichts im Wege - sofern man Windows nicht richtig traut oder als zusätzliche Sicherheit - erstmal RAID-Volumes als Basis für den Aufbau zu nehmen. Und noch eine gute Nachricht: Bei Pools funktioniert Trim trotzdem! sowohl mit NTFS als auch mit dem neuen. Habe da einen kleinen Fehler gemacht (leicht zu kleines Files für den Trim-Test verwendet). Zum ZFS: Das ist eigentlich richtig nett. In der höchsten Ausbaustufe, die allerdings auch nicht günstig zu haben ist, sogar mit transparentem Failover über mehrere Nodes. Dazu extrem gutes Dedup, übelste Performance (trotz verwendung von SATA Platten, weil Read und WriteCaching machbar, sowohl mit SSD's als auch mit RAM). Da kannst zbsp. auch pro Block jeweils Doppel, Dreier, Viererpakete von HDD's oder soviel Du willst machen. Die DiskBlocks hängst dann zusammen. Speichererweiterung in dem du einfach einen identischen Block wieder dazufügst. Windows geht da aber weiter, da hängst einfach Platten rein und definierst in der virtuellen HD, was für Voraussetzungen sie erfüllen muss. Entweder mit JPOD's auf welche mehrere Server gemeinsam Zugriff haben oder eben auch direkt mit lokalen Discs. @ChristianZ: Die HostCPU muss Paritäten berechnen, das braucht sicher etwas mehr Leistung als Mirror-Lösungen. Da habe ich noch keine Tests gefahren, ist aber auch nicht meine Priorität. Ich verwende "nur" Mehrfachspiegel. Aber wie gesagt, bei den Leistungen welche heutige CPU's bringen, zusammen mit dem RAM-Cache, ich glaube da müssen sie sich den wenigsten Einsteiger oder Mittel SAN's geschlagen geben in Sachen Performance und mit den neuen Features sicher auch in Sachen Flexibilität. ;)

Anhang: Wie gesagt, der einzige Unsicherheitsfaktor den ich aktuell sehe - und auch schon genannt habe - ist was passiert wenn eine Disc sich langsam verabschiedet. Wie entscheidet Windows welche Disc nun der Übeltäter ist und teilweise falsche Sektoren liefert. Bei Dreifachspiegel wird er wohl sinnvollerweise jene behalten, welche die gleichen Ergebnisse liefern und die falschen nach zu vielem Vorkommen und selbstreperatur kappen. Werde ich bei Gelegenheit mal testen indem ich mutwillig manuell Müll auf die Sektoren schreibe. Wenn das funktionieren würde und er die zwei "guten" als Referenz nimmt und die "schlechte" selber repariert und nach zuvielem Vorkommen abhängt, Hut ab. Theoretisch sollte das SMART bei Enterprise-Laufwerken aber eh zuverlässig selber ankündigen. Zusammen mit iSCSI (was dankbarerweise auch endlich legal verwendet werden darf und nicht nur in Testlabs oder bei kauf des Storage-Servers) würde sich das ganze sogar komplett über mehrere Gebäude/Brandabschnitte zusätzlich gespiegelt erstellen lassen. Hochverfügbarkeit mit Standard-Server-Hardware und Transparentem Failover sowie teilweise Scale Out (also lesen von allen Nodes). Für die absolute Paranoia ;) Zu guter Letzt: Trim funktioniert bei der Nutzung von Pools leider nicht... Eventuell aber auch mit manuellem Killen von Sektoren Script/Anstossbar.

@zahni: Danke für die Anregungen. Die Anmerkungen die Du nennst habe ich vorher selber bereits angeführt (HotSwap, Systemlaufwerk etc.) und auch entkräftet. Siehe auch weiter unten, etwas ausführlicher. ;) Systemlaufwerk : darum ging es zwar nicht sondern um Datenplatten für VM's aber habe ich jetzt nicht extra getestet. Gehe davon aus, dass sich da nichts geändert hat (Diskbootsektoren). Dem kann man schon frühzeitig beikommen indem man sie direkt nach Erstellung des RAID's manuell auf den Spiegel schreibt oder die entsprechenden Werkzeuge bereit hält um es im Schadenfall zu tun. Ging früher schon. Aufwand ist für ersteres ist minimal. Zweiteres auch kein Hexenwerk wenn man wusste wie HotSwap : War das absolue KO-Kriterium für diese Funktion Sah aber früher auch ATA-Hotswap Systeme wo sogar das funktioniert hat, auch wenn ich es auch nicht glauben wollte. Genau das Funktioniet jetzt aber absolut tadellos. Habe während der ganzen Tests diverse unterschiedliche Workloads parallel laufen lassen Zugriff war nie unterbrochen.Auch nicht bei einem Benchmark I/O Test. Nicht beim Crashen, Entfernen der Offline Disk, Wieder spiegeln auf neue Disc usw. Sonst hätte ich den Thread sicher nicht eröffnet und das ganze nur als Lab-Spielerei abgetan. ;) Was mich überhaupt auf die Idee gebracht hatte, waren die neuen Features von Server 2012. MS wird kaum solche Funktionen ankündigen, wenn es nicht auch zuverlässig wäre. Also muss Hotswap funktionieren. Tut das, sollte es auch mit dynamischen Discs. Performance-GAU: Der ist minimalst mit aktuellen CPU's und beträgt unter Vollast 2-3% der CPU Auslastung, welche auch ohne Spiegel schon fast erreicht ist. Write IOPS gehen kaum feststellbar verloren im Vergleich zu einzelnen Discs, die Differenzen hatte ich auch bei Single-Discs. @Blazilla: Datacore und ZFS war wegen der Pauschalisierung, dass Software-RAID nix ist aufgeführt, nicht wegen SSD, Trim oder so. Das man auf nem einzelnen Node ein RAID als Untergrund hat, macht sicher auch bei Datacore Sinn. Was ich da meinte war ein Software-Spiegel über mehrer Nodes, welches den Guests präsentiert wird. ;) Bemerkung zum Server 2012: Der ist der Knaller wie ich finde. Bei der Verwendung der neuen Speicher-Features von Windows Server 2012. Speicherpools, welche quasi eine Erweiterung der dynamischen Datenträger sind, aber keinen Zusammenhang mit den beteiligten Festplatten haben. Windows macht Daten einfach irgendwo drauf wos Platz hat und schaut dass die Daten mindestens zwei oder auf Wunsch auf drei verschiedene physische Datenträger sind. Funktioniert astrein. Konnte das Dateisystem nicht korrumpieren. Nicht NTFS und das neue ReFs schon gar nicht (soll sich ja selbstheilen wens trotzdem vorkommt) Analysiert man die Daten auf den physischen Datenträger und den virtuellen Datenträger (die Datenrettungstools unter Windows erkennen alle, Windows Datenträgermanager nur noch die virtuellen) werden die Daten 1:1 abgelegt wie auf der virtuellen. Windows muss das intern irgendwie verlinken. Ist mit Datenrettungstools daher möglich trotz der Speichervirtualisierung die Daten wieder von den Festplatten zu holen bei einem absoluten Totalausfall. Brauche ich mehr Platz, hänge ich einfach Festplatten beliebiger Grösse rein, fügt sie dem Pool hinzu und habe wieder Platz. Bei Ausfällen: Hier macht Windows den Job gleich selber und stellt den Krempel einfach auf einer anderen Platte wieder her. Man kann man sogar extra HotSpares-Drives definieren. Ganz wie in physischen Speichersystemen. Kombiniert man das nun alles mit den neuen Transparenten Failover-Funktionen bekommt man für SMB 3.0 fähige OS für wenig Geld Enterprise-Features von sauteuren Storage-Lösungen. Dann noch der ReadCache im RAM (Bis 20%) und das Zeug rennt wie Hölle. Soweit die Theorie. Praxis wird sich zeigen. ;)

@Dr: Ich weiss schon das es Dir unheimlich schwer fällt jeweils eine Begründung für Deine Aussagen zu liefern, daher nochmals, kannst Du das begründen? Nur einfach sagen es ist nonsens kann jeder. ;) Ich versuche es Dir noch einfacher zu machen: Zum Beispiel: Ob Du Erfahrung mit dem Feature gemacht hast oder welche kennst die es - in der Neuzeit mit Serverhardware (2k8/2012, SSD) - haben. ODER Dein (mein) Punkt 1 oder 2 Argument genug sind ... @Zahni: Auf alle Fälle Danke, das war immerhin etwas zum Thema. :)

Solche Produkte sind mir auch bekannt, das ist aber nicht sehr realisitisch für kleinere Betriebe. Der zweite Link klingt schon eher nach 'Otto-Normal-Betrieb' finanzierbar. Allerdings konnte ich auf die schnelle nicht wirklich etwas finden ob Trim in einem RAID-Verbund tatsächlich funktioniert. Zurück zum Windows-Software-RAID: Mir sind die Probleme von früher durchaus bekannt, habe als das aufkam auch diverse Tests gefahren und für untauglich befunden. Dazu dann diverse Restores und Rettungen Durchgeführt welche andere aufgesezt hatten. Lag aber meistens an nicht 100%ig funktionierender HotSwapTechnik, Anwendung auf Systemlaufwerke (Probleme beim Reboot, Bootsektoren) und instabile Systeme, Windwos das sich daher aufhängte etc. Die Probleme von damals konnte ich aber nicht reproduzieren (Systemlaufwerk ausgenommen). Einfach pauschal das ist nix weil das Feature mit früheren Hardwaregenerationen zu Problemen führte finde ich etwas naja. Eine Begründung würde mich daher brennend interessieren. Ich sehe Aktuell zwei Probleme: 1. Wie reagiert Windows wenn ein Laufwerk langsam stirbt, also einfach sektoren mit müll raus lässt anstelle sich ganz auszuklinken. Bis dato habe ich aber nur letzteres bei SSD's gesehen/gehört. 2. Was passiert wenn der Host stirbt. Das Problem mit Filesystem-Sauereien kann man da immer haben, sollte aber mit einem Batteriegestützten Controller kleiner sein. Waren noch nicht alle Infos beim Controller, nützt es auch da nix. Die Überwachung ist wieder eine andere Sache. Müsste man dann logischerweise einen Trigger bauen. Tut aber nichts zur Sache ob das RAID an sich tauglich ist oder nicht. Von daher, wenn sich ein paar Profis mit Erfahrungen mit Systemen von Heute diesbezüglich melden würden wäre das Klasse.

Ich traue den SSD's ned mehr oder weniger als einer Enterprise SAS-Disc. ;) RAID-Controller mit Trim-Unterstützung als normale PCI-Express-Karte dazu mit gutem IO Durchsatz? Bitte melden. ;) Software-RAID: Auch ZFS ist ein Software-RAID und funktioniert prächtig und extrem performant. Ebenso Datacore, welches sogar auf Windows-Server-Basis läuft. Alos pauschalisieren kann man es nicht. Auch MS geht mit Ihrer Entwicklung im Storage-Bereich in diese Richtung. ;) Das Standard-Software-RAID von Windows ist bei entsprechender Hardware ziemlich robust. W-Server sowieso. BlueScreens hatte ich im Betrieb schon ewig nimmer. Da es aktuell nichts vernünftiges und bezahlbares für SSD's mit Trim auf PCI Basis gibt (mir ist zumindest nichts bekannt, lasse mich gerne belehren), finde ich das eine gute Lösung bzw. besser als eine Single Disc. Abhängen tut Windows ein Volume auch nicht mehr wenn wenn ein Spiegelpartner weg ist. War früher - soweit ich mich erinnere - ein Problem. Zumindest konnte ich problemlos eine Disc herausziehen und Volume war immer noch verfügbar. Neuen Datenträger rein und wieder syncro. Sehe das ganze für VDI, da geht der Trend richtung Local-Disc Storage auch bei grösseren Installationen, weil die IOPS halt extrem günstig sind. ESX und Trim: Sofern es nicht mit 5.1 gekommen ist. Ja. Aber auch da bin ich der Meinung das es noch nicht geht. Angeblich auch eher schwierig, weil das Hostsystem mit dem aktuellen Format nicht mit dem Guest-System kommunizieren kann und ein Datestore meines Wissens auch nicht. Wäre also wenn dann nur via wachsenden Discs, NFS und regelmässigem Shrinken zu erreichen. Den Komfort wie in HyperV hat man nicht.

Danke für die Blumen. Das sollte aus dem Text und Titel zwar klar ersichtlich sein, aber für Dich lasse ich natürlich gerne eine Erklärung folgen. ;) Trim funktioniert in der Regel nicht mit SSD die in einem RAID-Verbund sind. Weder im Hardware noch Software-RAID. SSD wird mit der Zeit extrem lahm. Sucht man im Netzt danach findet man auf die Frage nur die Antwort, dass man die Trim-Funktionalität verliert sobald RAID eingesetzt wird. Da man je nach Situation vielleicht mit Local-Storage arbeiten möchte/muss (Ja das gibt es bei Kleinumgebungen) kann man so trotzem ein sehr schnelles System, mit Trim-Funktionialität und RAID bewirtschaften. Nicht jeder kann und will 10'000 Euro für ne SAN-SSD ausgeben, dessen Performance aber vielleicht trotzdem haben. Zusammen mit RAID. Des weiteren: Wenn die Hyper-V-Guest ihrem Host mitteilen welche Sektoren frei sind und dies gleichzeitig auf den SSD's geschieht ist das ein ziemlich hilfreich für die SSD. Weil so die SSD eben nicht ganz zugemüllt wird, obwohl von der virtuellen Disc allokiert. Zumindest wenn MS da keinen Schmarrn erzählt. Ist gegenüber VmWare aktuell ein Vorteil.

Hallo Leute, Habe ein paar Tests gefahren weil ich dazu keine befriedigende Antwort im Netz gefunden habe. Kann definitiv sagen, dass es mit einem E5, C600 Chipsatz, Windows 7, Intel SSD 520 funktioniert. Überprüft wurde das ganze mit einem HexEditor auf Datenträger-Ebene. Ist Trim in Windows deaktiviert, bleiben die Sektoren nach dem löschen einer Datei gefüllt. Wird Trim aktiviert, werden Sie gelöscht, auf beiden Datenträger. Nachträgliches aktivieren von Trim bewirkt nicht, dass die Sektoren gelöscht werden. Jedoch hat Windows diese Sektoren jeweils prioritär wieder überschrieben wenn neue Daten hinzukamen. Das gibt ein paar schicke neue Möglichkeiten für Local Storage für HyperV VM's (Angeblich weitergabe von gelöschten Sektoren mit SMB 3 und HyperV3) und evtl. Sogar Hochverfügbarkeit mit Boardmitteln (iSCSI, Cluster). Jedoch noch nicht getestet. Hoffe das hilft dem ein oder anderen. Mir war das immer ein Dorn im Auge mit den SSD's und der Ungewissheit wenn mir eine wegstirbt. Was allerdings Windows macht, wenn eine aus dem Spiegel stirbt, weiss ich auch nicht so genau. ;)

Das ist doch Quatsch mit den drei Lizenzen?!? Also Du hast korrekte Lizenzen für 2008 und für den SBS. Was du brauchst ist eine einzige 2012 Standard Lizenz damit Du einen Hyper-V Host hast, welcher eine GUI hat. Du dürftest imho in dieser Konstellation sogar 2 zusätzliche virtuelle 2012er laufen lassen, da die anderen ja vollständig lizenziert sind. Sollte MS sich wirklich querstellen und behaupten man brauche zusätzlich 2012er Lizenzen für alle 2008er Server instanzen (welche über eine Lizenz verfügen), ist das rechtlich eher schwierig. Die müssten sich darauf berufen, dass die Virtualisierungstechnologie 2012er Technolgien sind und somit alle Clients mit der neuen Technologie lizenziert werden müssen. Allerdings auch schwer haltbar, wenn man gleichzeitig die Technolgie umsonst anbietet (ohne GUI). Insofern würde ich mir keine grossen Sorgen mochen. Zur Sicherheit - wenn Du keine vernünftige Antwort bekommst -, nimmst eben einfach VmWare Essentials wenn sie sich querstellen. Da benutzt du dann keine Sever 2012 Technolgie für die Virtualisierung und somit gelten auch die Einschränkungen nicht.