Cluster vs. Replizierte server

[finace23 0]

Hallo, 

 

ich betreue gerade geschäftlich die Umstellung des bestehen MS SBS Systems (2011).

 

Mir liegen 2 unterschiedliche Konzepte vor und ich fasse diese gerade für die Geschäftsführung zusammen.  

 

Konzept 1 

 

2 Replizierte Server

 

Konzept 2 

 

2 Cluster Server mit einem Storage 

 

Nur um sicher zugehen , bei einem Replizierten Server liegen die Daten 1:1 gespiegelt auf dem 2 Server , im Failover Fall übernimmt der 2 Server die Dienste des 1 Server ? 

 

Beim einem Cluster Server habe ich 2 Getrennte Systeme: Server 1 kann VM A, B ,C und Server 2 D , E usw. bzw, ich sage VM D und E laufen auf Server 1 

 

Ist dies so korrekt ? Bzw. welche Vorteile / und Nachteile weisen die beiden Konzepte auf? 

 

Die Kritischen Komponenten sind in beiden Konzepten Redundant aufgebaut. Die Überlegung geht noch dahin beim Storage 4 h Reaktionszeit auf den Support zulegen. 

 

Als OS kommt MS DataCenter 2012 R2 zum Einsatz. 

 

Ich freu mich auf eure Antworten. 

 

VG

Thomas 

[NorbertFe 1.805]

Exchange unterstützt kein Replika. Das solltest du bei deiner Planung berücksichtigen.

 

Und ansonsten unterscheiden zwischen Application/service availability und Host availability. Mit dem sbs bekommst du ersteres nicht redundant hin.

[finace23 0]

Exchange bleibt nicht bestehen (Migration zu Office 365) und der SBS wird aufgelöst. Dienste werden im Server 2012 R2 künftig ausgeführt.  

 

Was meinst du mit zwischen Application/service availability und Host Availability ? 

 

Welches Konzept ist in euren Augen das bessere, bei einer 5 Jahresplanung? 

bearbeitet 12. Dezember 2015 von finace23

[NorbertFe 1.805]

Na überleg mal, was ich damit meinen könnte. ;)

[Doso 77]

Nein, bei Replizierung geht nix automatisch. Da musst du im Fehlerfall selber die Server umbiegen und anschalten. Automatisch geht dann nur mit Failover Cluster. Vor und Nachteile kannst du dir selber erooglen, da gibt es gefühlt Millionen Artikel dazu.

[magheinz 100]

Das hat wenig bis gar nichts damit zu tun für welchen Zeitraum du planst. Welche Anforderungen hast du für welchen Service in Sachen tollerierte Ausfallzeit und tollerierter Datenverlust?

 

Wir setzen auf beides, je nach Bedarf.

[NilsK 2.785]

Moin "finace23",

 

so leicht lässt sich das nicht bewerten. Solche Fragen sind für ein Forum nicht geeignet.

 

Ich illustriere das mal mit einer Analogie: Deine Frage entspricht in etwa der Frage "was ist besser, ein 3er-BMW oder ein Mercedes Sprinter?"

 

Gruß, Nils

[magheinz 100]

Wenn klar ist das er täglich 200 Umzugskisten transportieren will sollte ein Forum die richtige Antwort finden...

Ich liebe Autovergleiche.

 

Also Anforderungen definieren oder definieren lassen und dann das richtiges Konzept auswählen, nicht andersherum.

Um deine Frage zu 1. beantworten zu können fehlen Infos zur geplanten Umsetzung.

Um deine Frage zu 2. beantworten zu können fehlen Infos zur geplanten Umsetzung.

 

Vor und Nachteile lassen sich erst beschreiben wenn die beiden Fragen geklärt sind.

Was ist als Hypervisor geplant? Windows? Vmware? Welche Ressourcen werden benötigt und kann ein Server alles geplanten VMs bedienen etc.

 

Abgesehen davon: Ihr müsst doch als ihr die Angebote angefragt habt überlegt haben was ihr haben wollt? Daraus sollte dich doch ergeben welches der Angebote das Angefragte erfüllt und welches nicht.

 

Aus Neugierde: was wäre den der geplante Storage für ein Model?

[lefg 276]

 

..... , bei einem Replizierten Server liegen die Daten 1:1 gespiegelt auf dem 2 Server , im Failover Fall übernimmt der 2 Server die Dienste des 1 Server ?

 

Ist das denn so vereinbart, sichert der Auftragnehmer das denn so zu?

bearbeitet 13. Dezember 2015 von lefg

[DocData 85]

Nur um sicher zugehen , bei einem Replizierten Server liegen die Daten 1:1 gespiegelt auf dem 2 Server , im Failover Fall übernimmt der 2 Server die Dienste des 1 Server ?

Leider total falsch. Bei einer Replikation können Daten NIE gespiegelt vorliegen. Eine Replikation hat immer den Nachteil, dass ein Teil der Daten verloren geht. Es gibt immer einen zeitlichen Versatz zwischen Daten auf System 1 und System 2.

 

 

Beim einem Cluster Server habe ich 2 Getrennte Systeme: Server 1 kann VM A, B ,C und Server 2 D , E usw. bzw, ich sage VM D und E laufen auf Server 1

Ein Cluster ist immer ein Verbund von Servern. Die Systeme sind daher nie getrennt. Geht man hier konkret von einem Cluster von Virtualisierungshosts aus, so kann man sagen, dass jeder Server in dem Verbund virtuelle Maschinen betreiben kann. Fällt ein Server im Verbund aus, können die ausgefallenen (!) virtuellen Maschinen auf den verbleibenden Servern neu gestartet (!) werden. In der Regel hat man hier ein kürzeres RPO und eine kürzere RTO als bei einer Replikation. Wobei ich beide Techniken unabhängig von einander sehen würde.

 

Ist dies so korrekt ? Bzw. welche Vorteile / und Nachteile weisen die beiden Konzepte auf?

Ähh... du berätst doch die Geschäftsführung?!

 

Die Kritischen Komponenten sind in beiden Konzepten Redundant aufgebaut. Die Überlegung geht noch dahin beim Storage 4 h Reaktionszeit auf den Support zulegen.

Was nichts anderes heißt als: Nach 4 Stunden sagt dir jemand, dass er ein Ticket aufgemacht hat. Die Reaktionszeit hat NICHTS mit der Wiederherstellungszeit zu tun. Du solltest also eher auf Supportverträge mit Wiederherstellungszeiten abzielen. Alternativ kein zentrales Storage und auf Systeme wie VMware VSAN setzen.

 

Als OS kommt MS DataCenter 2012 R2 zum Einsatz.

Also hast du den Hypervisor schon festgelegt?

[Weingeist 157]

Die Glaskugel sagt:

- SBS, Kleinunternehmen

- Bis jetzt hattet ihr nix mit Replikation, Always-On, Lockstep und enorm kurze Ausfallzeiten am Hut.

 

Ergo muss man sich fragen ist das tatsächlich gebraucht wird oder ob es einfach nur unter die Kategorie lästig geht wenn die Systeme maximal ein paar Stunden flach liegen oder ein paar Stunden Daten weg sind und einfach wieder eingegeben werden können. Das meinen die Jungs hier mit Anforderungen definieren. Ein paar Stunden Arbeit rechtfertigen z.B. selten die Kosten von Replikation- oder FT-Lösungen. Nicht nur von der Anschaffung sondern auch im Unterhalt.

 

In fast jeder Kleinumgebung ist es sinnvoller sich das ganze TamTam mit Replikation, Cluster oder FT zu sparen und die Backupstrategie, sowie Primär- und Backupspeicher entsprechend performant auszulegen damit ein Restore sowie die Sicherung in der gewünschten Frist gemacht ist. Notfalls mit SSD-Systemen auf beiden Seiten.

Das brauchst bei den FT und Replikations-Geschichten neben dem entsprechenden Know-How nämlich sowieso wenn die Anforderungen entsprechend hoch sind und ein solches System in Erwägung gezogen wird. Sprich die ganze Software und Hardware ist immer zusätzlich und kostet ein Vermögen. Die Fehleranfälligkeit für Misskonfiguration + falscher Reaktion im Fehlerfall (egal ob automatisch oder manuell) oder bei  Hardwarefehler ist zudem bedeutend höher und sollten entsprechende Spezialisten machen.

 

Eine normale Backup-Recovery Umgebung kriegt auch ein normaler IT-Techniker gut hin. Und auch hier bekommt man die Kohle schneller raus, als einem lieb ist wenn man es auf die Spitze treibt. Sprich das meiste davon muss eigentlich schon vorhanden sein, bevor man über die "richtigen" Always-On System nachdenkt.

- Mehrere Server, Ersatzteile vor Ort, Kompletten Ersatzserver

- Sehr schnelle storage-Systeme für schnelles Full-Recovery beim Primärspeicher sowie Backup welche mehrfachsicherungen pro Tag zulassen

- Infrastruktur redundant

  - jeweils zwei potente USV's für Primärsystem und Backup in separaten Brandabschnitten oder Gebäuden

  - separate Absicherungen im Stromkasten

  - evtl. zwei getrennte Einpeisungen vom Stromanbieter

  - Notstromaggregat

  - zwei ISP's für Internet, Backupanbindung über Mobilfunknetz usw.

  - Switches, Sämtliche Netzteile usw.

 

Klar kann man auch Kompromisse an den ein oder anderen Stellen machen, vorher muss man aber eben definieren was tatsächlich wichtig ist.

- Ist es wichtig dass keinerlei Daten weg sind wie z.B. wichtige Live-Aufzeichnungen von Prozessen die nicht mehr wiederbeschafft werden können *1)

- Ist es wichtig, dass die Systeme immer verfügbar sind oder spielt es nicht so die Rolle wenn mal ein paar Stunden nix geht (sprich z.B. einfach 5 Leute nix arbeiten und nach Hause geschickt werden müssen)

- Ist alles zusammen extrem wichtig fürs Geschäft

- usw.

 

zu 1*) auch hier gibt es vielleicht sinnvollere Ansätze als FT/Replikation. z.B. Anpassung der Software z.B., dass sie direkt auf zwei unabhängige Ziele schreibt.

 

 

Von daher wie die Vorredner schon sagten: Es gibt Vor- und Nachteile von verschiedenen Lösungen nur in Abhängigkeit von dem, was man erreichen möchte, was tolerierbar ist und im Endeffekt finanziert werden muss.

[lefg 276]

Der TO war zuletzt am 13 Dec am Board aktiv.

bearbeitet 29. Dezember 2015 von lefg