bla!zilla

Gar kein Problem. Das Routing innerhalb des MPLS ist für euch transparent. Der CE Router hat eine IP in eurem Netz und ist dann das Gateway hin zum Standort.

Danke. :) Ich hab noch das gefunden: The basics of SMB Multichannel, a feature of Windows Server 2012 and SMB 3.0 - Jose Barreto's Blog - Site Home - TechNet Blogs Schaut ja ganz nett aus. Auf jeden Fall eine bessere Implementierung als NFS in der VMware Welt.

Alles andere ergibt bei diskbasierten Systemen auch wenig Sinn. Außer man muss Geld loswerden... Bei Preis pro Gigabyte zeigt das Tape der Disk trotzdem die Rücklichter... Geht selbstverständlich auch mit Tape. Räumliche Trennung ist kein Argument für oder gegen Diskbackups. Es ist eine allgemeine sinnvolle Maßnahme bei Datensicherungen. Ein wunderbar konstruiertes Szenario in dem das Diskbackup gewinnt. In der Praxis, gerade mit einem Blick in Richtung Netapp oder ZFS-basierter Storagesysteme, durchaus praktikabel. Das Ziel eines kurzen RTO ist damit in jedem Fall erreicht. Aber RTO ist eben auch nicht alles. Von VSS und Disaster Recovery hat auch niemand gesprochen. Wenn doch, dann bitte mal kurz zitieren. VSS ist im Rahmen eines Datensicherungskonzeptes ein quick Win. Nicht mehr, nicht weniger. Ein diskbasiertes Backup zur schnellen Wiederherstellung von Publisher Grußkarten zu betreiben ist... äh... na ja. Und ja, VSS ist nice to have. Aber die schnelle Wiederherstellung von einzelnen Files als Pro-Argument bei diskbasierten Sicherungen ist mittlerweile Murks.

Keine Sorge. Du kannst selbstverständlich getrennte IP Subnetze verwenden. Layer-2 VPNs sind nur eine Anwendungsmöglichkeit von MPLS. Der ISP wird euch zwei CE Router stellen, ihr setzt das Routing auf wie ihr es braucht, der Weg durch das MPLS ist für euch völlig transparent.

Lesen und im Kontext sehen. :rolleyes: Wenn ich eine Datei wiederherstellen will, dann ist VSS super und genau dafür ist es gedacht. Ich will nicht für jedes versehentlich gelöschte oder überschriebene File das Tape anwerfen. Und die wenigsten Kunden machen sich Gedanken über ein ECM. Und nur für den schnellen Restore ein Backup-2-Disk vorhalten? Betriebswirtschaftlicher Unsinn. Wenn mir mein Storage abraucht, dann habe ich hoffentlich eine funktionsfähige Datensicherung und einen funktionierenden Recoveryplan.

Ich würde nur zwei DCs in der virtuellen Umgebung laufen lassen. Ein Managementhost/ Backuphost sollte nie so kritisch sein, wie es ein DC ist. Du kannst auf jedem der beiden ESXi einen DC laufen lassen und über Autostartup die DCs beim Start bzw. Shutdown eines oder beider ESXi Server rauf- oder runtefahren lassen. Wichtig: Keine Snapshosts von den DCs machen bzw. zurückspielen. Sichere den Systemstate der beiden Kisten.

Okay, denkbares Szenario. Interessanter Punkt, sehe ich ähnlich. Live Migration zwischen Storage Systemen ist nett, aber wird eigentlich nur für Migrationen gebraucht. Kommt eher selten vor. Da bin ich mal richtig gespannt. NFS in der VMware Welt ist ja nichts Neues, aber hat auch so seine Tücken. Das wird bei SMB 3.0 nicht anders sein. Weiß jemand wie sich SMB 3.0 bei mehreren Links verhält? Verteilt sich die Last beim SMB 3.0 Zugriff auf ein Volume über mehrere Links oder sitzt jede Session dann auf einem Link. Oder vielleicht sogar nur eine Session pro Zugriff? Wenn es nur am Rande ist, schick mir das nächste Mal eine PN. In wie weit ich die Wünsche meiner Kunden kenne kannst du schlecht beurteilen. Es kommt auf dem Standpunkt und das Umfeld an, von dem man aus bestimmte Problemstellungen betrachtet. Es ist halt die Frage ob man einer Gleisarbeitergruppe angehört die bei Bedarf auch die Einfahrt pflastert, oder ob man als Architekt auf Großbaustellen arbeitet.

Soweit ein Einwand. Es muss aber die Frage erlaubt sein: Enterprise Features für Kunden die keine Enterprise Features brauchen? ;) Und wenn sie Enterprise Features brauchen, dann sollte vielleicht auch das Budget vorhanden sein, oder? Meine Erfahrung zeigt: Kunden, die Enterprise spielen wollen, aber kein Geld dafür ausgeben können/ wollen, haben meist noch ganz andere Baustellen. Aber wieder zum Thema: Ist ja schön da sowas nun funktioniert. Bleibt die Frage: Wie zuverlässig ist es und welches Problem löst es. Features die Probleme lösen die man erst Konstruieren muss sind irgendwie... mmh... na ja.

Klar, sofern die VM nicht in einem Shared Filesystem liegt ist das so. Frage ist: Will man das?

Beliebter Irrglaube und die Krücke in vielen Backupkonzepten... Warum mache ich ein Backup-2-Disk-2-Tape? Drei Möglichkeiten: 1. Ich will Daten auf Disks vorhalten, da der random Access im Recoveryfall schneller ist als das langwierige Spulen auf einem Tape, vor allem wenn es nur ein File ist. Aber: Warum hole ich das File aus der Datensicherung, wenn ich z.B. Microsoft VSS habe? Je nach Datenmenge kann ich maximal ein paar Tage auf Disk vorhalten und muss danach eh auf das Tape ausweichen. VSS geht in vielen Fällen sehr viel länger zurück. 2. Ich habe ein Problem mit meiner Performance und will das Tape nicht quälen. Also schiebe ich die Daten auf Disks zusammen und dann per Copy auf Tape, wobei ich hier einen langen, durchgehenden Datenstrom garantieren kann. Hier sollte ich mir mal Gedanken um mein Backup Konzept machen. Warum ist mein Backup so lahm? Ein LTO-5 rotzt mir schnell mal 280 MB/s auf Band. Das schafft man natürlich nicht von mit einem Server... Per NDMP von einem Netapp Filer geht das schon eher. Und LAN-free Backup eines Fileservers mit entsprechend Storage dahinter (nein, keine SSD... -.-) dann sehr sicher. Multiplexing ist auch eine gute Idee um ein Laufwerk füttern zu können (wo liegt meine Prio? Schnelles Backup oder schneller Restore?). Des Weiteren liege ich hier bei der Gesamtlaufzeit meines Backups (Backup auf Disk und dann Copy auf Tape) deutlich über der Laufzeit eines direkten Backups. 3. Ich sichere auf eine VTL o.ä. und schiebe die Daten dann auf Tape, um sie zu exportieren (Safe o.ä.). Machen wir uns mal nix vor: Disks als Backupmedium ist das energetisch uneffektivste was geht. Sie haben, je nach Backupkonzept ihre Daseinsberechtigung, gerade wenn wir bei größeren Umgebungen z.B. über VTLs und so tolle Sachen wie Deduplication reden. Aber sonst... Lieber etwas länger über die richtige Software und das Konzept nachdenken, statt einfach ein Backup-2-Disk-2-Tape zu implementieren. Vor allem an den Brandfall denken... Disks passen so schlecht ins Schließfach.

Joar, was soll ich zu Server 2012 sagen? Funktioniert... Irgendwie noch grausig zu administrieren und die neuen Features müssen mal zeigen wo die tatsächlichen Mehrwerte liegen. Aber so auf den ersten Blick scheint es kein Windows ME zu werden. Mmhh... Unterbrechung auf Grund deiner Testumgebung oder ist das "by Design"?

Die Stripesize oder Chunksize kannst du bei den meisten Controllern konfigurieren. Gibst du die Chunksize an, erhälst du über die Gesamtanzahl der Platten im RAID die Stripesize. Hast du die Stripesize, dann kommst du über die Gesamtanzahl der Platten im RAID zur Chunksize. Nun brauchst du wieder die IO Größe. Ist die IO Größe kleiner als die Chunksize, dann hast du wohl einen short IO... Bleibt die Frage ob du MB/s haben willst oder viele IOPS. Soll jeder IO nur genau eine Platte beschäftigen, oder sollen sich mehrere Platten um einen IO kümmern?

Jein. Es kommt darauf an wie es der Controller organisiert und ob es ein long oder short IO ist. Bei einem Short IO (also ändern eines Chunks in einem Stripe) sind es vier IOs: 1. Chunk lesen 2. Parity lesen 3. Chunk schreiben 4. Parity schreiben Wird der ganze Stripe geschrieben, dann kann sich der Controller das Lesen vorher sparen und direkt in einem Rutsch durchschreiben. Der dritte IO ist dein eigentlicher, effektiver IO. Der Rest ist Overhead und wird als Write Penalty bezeichnet. Deswegen sind paritätsbasierte RAID Level (RAID 3, 4, 5, 6 etc.) bei short Writes eine schlechte Wahl. Außer man hat entsprechend viele Platten...

IO Größen kannst du messen. Ansonsten gibt es ein paar Standardwerte, die sich in der Praxis bewährt haben. Zum Beispiel arbeiten die meistne Datenbanken mit 4k bis 8k IOs, Exchange z.B. mit 32k etc. Theoretisch ja. Nun hängt es aber davon ab ob es Read oder Write IO ist, ob short oder long IO, random oder sequential IO. Ist doch logisch, oder? Die Platte schafft in Summe eine bestimmte Anzahl IOPS. Wenn du nun liest und schreibst, vielleicht sogar random und sequential, dann kann dein konkreter IO Vorgang nur eine Teilmenge davon nutzen. Hängt halt auch vom IO Verhalten des Betriebssystems ab, wie es IOs priorisiert, von der Queue Tiefe etc. Kommt darauf an. Du testst hier vom Betriebssystem aus. In Richtung des rotierenden Rostes kommen noch Software, Bussysteme, Cache etc. Warum sollte das nicht so sein?

Der SAN Design Guide setzt aber schon auf einem recht hohen Level an und bezieht sich nur auf FC Fabrics. Einen Teil der Informationen kann man durchaus auf andere Hersteller übertragen: C-Series sind Cisco MDS, H-Series sind Qlogic, B-Series sind Brocade, und M-Seriess ind McData Switches (schon vor einiger Zeit von Brocade geschluckt). Aktuell wird hier ja nur über RAID Level und IOPS gesprochen. Meist krankt es an Bauchentscheidungen bei der Plattenauswahl und -anzahl, bzw. wenn da genug Leistung vorhanden ist, verpufft das gerne mal in schlechten Fabrics bzw. schlechten iSCSI SAN Designs.

Nein, das spart dir sicherlich nicht den Einsatz von SSDs. Der Cache hat noch ein paar andere Funktionen. Wenn du einen Usecase für SSDs hast, dann setz welche ein. Ich halte die Einsatzmöglichkeiten für SSDs immer noch für sehr beschränkt, zumal die Leistung in vielen Umgebungen einfach verpufft. It depends on... Es kommt auf den Workload an und wie ein RAID Controller das Ganze optimiert. Dein größtes Problem ist die Write Penalty, und die trifft dich vor allem bei Short Writes. ... und eine noch viel schlimmere Write Penalty. Dazu kommt eine noch niedrigere Rate an effektiven IOPS. Korrekt. Gewagte Bauchentscheidung... It depends on... Es kommt auf deinen Usecase an. Wenn du kompromisslose Performance brauchst, gepaart mit hoher Verfügbarkeit, dann brauchst du RAID 1+0. Wie wichtig sind PS? IOPS sind IOs pro Sekunde. Und IOPS x IO Größe = MB/s. Eine ganze einfache Gleichung. Wieviele IOPS du brauchst, hängt von deinen Anforderungen ab. Natürlich machst du vor einem Virtualisierungsprojekt in Assesment und schaust dir die Systeme an. Misst und entwickelst dann eine Lösung. Wie hast du das gemessen? Mehr Platten = Mehr Performance und weniger Overhead. Nachteil: Mit jeder Platte steigt die Möglichkeit des Plattenausfalls in einem Array und damit auch die Möglichkeit eines Double Failures. Zudem bist du oft durch die Controller limitiert. Durch Tools des Herstellers oder geeignete Systemmanagementlösungen. Es ist deine Aufgabe das mit in die Lösung einzubinden. Sonst passiert das, was du bei deinem Kunden gerade siehst: Blindflug. Und wenn du dann wichtige Grundlagen nicht beherrscht, dann tappst du im Dunkeln und findest keinen Ausweg. Alles nur Vermutungen, aber keine stichhaltigen Anhaltspunkte für das Troubleshooting. Brocade FC Switches bringen z.B. Fabric Watch, Top Talkers etc. mit. Oder den Brocade Network Advisor oder SAN Health. Für Cisco MDS gibt es ähnliche Tools. Ethernet Switches (für iSCSI Umgebungen) lassen sich meist auch sehr gut monitoren, HP ProCurves z.B. mit dem ProCurve Manager. Wichtig ist aber, dass du die Basics verstanden hast.

Ah, okay. Dann habe ich deinen Beitrag missverstanden.

Nein, nicht mal in München. Die liegen vielleicht 10% bis 15% darüber, wird aber auch durch die höheren Lebenshaltungskosten direkt aufgefressen.

Es gibt bei Windows Active Directory keine Master/ Slave Funktionen. Das ist kein NIS.

Mea Culpa, ich hätte zitieren sollen. Ich bezog mich auf dein Posting und stellte mir die Frage: Was war falsch an der Aussage "Nicht vergessen, dass AD mit adprep zu aktualisieren:".

Beim ersten Durchlesen deiner Idee kam mit der Gedanke auch. ;) Geht. Geht. Gleiches Subnetz ist nicht notwendig. Wohl aber besser eine Verbindung via VPN Tunnel. Slave?! Seit wann sind Domain Controller Master und Slave? Du willst offenbar dein Büro als eigenen Standort mit einem weiteren Domain Controller betreiben. Fakt ist: Geht, aber nur per VPN Tunnel zwischen den Sites. Theoretisch ja, aber praktisch eine mehr als dumme Idee. Deine ganze Installation sollte im RZ hinter einer Firewall stehen. Zugriff nur per VPN Tunnel. Wenn du dann in deinem Büro auch eine Firewall hinstellst, und die beiden Netze per Site-2-Site Tunnel verbindest, dann geht das selbstverständlich.

Wo liegt das Problem? Er hat doch geschrieben, dass man vorher mit adprep die Domäne vorbereiten muss. Das damit der forestprep und der domainprep gemeint ist, sollte jedem einleuchten. Spätestens wenn man zur Vorbereitung der Aktion in die Technet schaut.

Nö, nicht wirklich. Besser wäre es, wenn du für den Export den VMware Converter oder Veeam o.ä. verwendest. Konvertiere die VM einfach per Converter in eine VMware Workstation VM auf deinem externen Datenträger und dann am Zielstandort vom externen Datenträger und als VMware Workstation VM wieder in eine VI VM.

Dem Exchange 2010 mag die GUI ziemlich egal sein, wohl aber nicht, dass einige Komponenten, die Exchange 2010 braucht, in der Server Core nicht vorhanden sind. Zum Beispiel der RPC-over-HTTP Proxy (braucht die CAS Rolle) oder der Indexing Service (wird von der Hub Role benötigt). Zudem sind einige RAST Sachen nicht verfügbar. Exchange 2010 lässt sich definitiv NICHT auf einem Server 2008 Core installieren und wird wahrscheinlich auch nicht auf einem 2012 Core funktionieren. Selbst wenn es funktioniert, wird es dafür keinen Support geben. Ich bin mir aber sehr, sehr sicher, dass der Exchange 2010 Nachfolger problemlos auf einem Core funktionieren wird. Beim SQL 2012 hat Microsoft es ja auch hinbekommen. :)

Völlig überzogen. In NRW vielleicht 22k bis 25k. In NRW sehe ich da eher 30k bis 35k. In NRW sehe ich da eher 35k bis 45k. Träumst du?? 45k bis 80k.