bla!zilla

Wenn wir schon über konkrete Produkte reden, dann schau dir mal Kemp an. Erstaunlich günstig, aber reichhaltiger Featureumfang. Bekommen ganz gute Kritiken und die virtuellen Appliances rennen ganz wunderbar.

Wenn Switch 1 über Switch 2 mit Switch 3 verbunden ist, dann musst du den Uplink zwischen Switch 2 und Switch 3, sowie den Uplink von Switch 1 zu Switch 2 ebenfalls tagged in das VLAN 100 packen. Du könntest die Ports auf dem separierten Switch aber auch untagged im VLAN 1 lassen und nur den Uplink von Switch 3 auf Switch 2 (auf dem Switch 2) untagged ins VLAN 100 packen. Dann ist der gesamte Switch 3 im VLAN 100. Und sofern das VLAN 100 tagged über den Uplink zu Switch 1 gezogen wird, kommst du von deinem Switch 1, VLAN 100 auch auf den Switch 3, der komplett im VLAN 100 steht. Eigentlich ganz einfach...

Du brauchst einen Load Balancer. Entweder Windows NLB (siehe Link von nerd), oder etwas in Richtung Kemp, Big IP o.ä.

Also solches Verhalten ist mir nicht bekannt, so ist z.B. HP Data Protector ist schon länger IPv6 ready. Möglicherweise sollte sich Legato (oder euer Lieferant) mal RFC 6540 ansehen... ;)

Hallo,

Ich würde einfach mal gerne eure Meinung dazu erfahren, vielleicht bin ich auch auf dem Holzweg ;)

ja, bist du ganz sicher.

ich würde gerne eure Meinung dazu erfahren. Ich plane unsere SBS 2003 R2 durch einen Win 2008 R2 zu ersetzen. Ich plane das Betriebssystem Virtuell auf einer VM ESXi zu betreiben, die Daten des Unternehmens allerdings auf einem NAS Laufwerk zu speichern und nicht in der virtuellem Win 2008 R2. Daten und System würden somit auf zwei unterschiedlichen Geräten arbeiten.

Das macht aus Gründen des Managements und der Simplizität der Installation keinen Sinn. Du solltest die Daten IN dem virtualisierten W2K8 R2 halten und die Daten, z.B. per Robocopy, auf das NAS kopieren (bitte zusätzlich zur hoffentlich vorhanden Datensicherung!).

Wo siehst du die Vorteile deines Konzeptes?

Ich arbeite in meinem Umfeld zwar mit ITIL aber das kleine Taschenbuch zu ITILV3 beinhaltet soviel zu ITIL ...

Also zwar Erfahrung mit ITIL, aber du hattest kein ITIL Training? Hmm... ganz ehrlich: Wird schwer. Die Prüfung ist mit Training eher einfach, ohne Training... na ja. Das Vokabular ist schon speziell und so wie es dir ein Trainer rüberbringt, schafft das kein Taschenbuch.

Ich muss mal gucken, ob ich in diesem Jahrtausend überhaupt in einem Jahr (falls überhaupt) unter 50.000 (incl. Bonus) nach hause gegangen bin.

Für einen Informatikkaufmann mit entsprechender Qualifikation und im passenden Unternehmen durchaus möglich, aber eben nicht die Regel.

Also mit einem simplen Dump & Restore wird es nicht getan sein. Du wird auf jeden Fall über unterschiedliche Datentyen etc. stolpern, evtl. über komplexe Stored Procedures (Oracle kannst nested procedures, SQL nicht.), Views etc.

Supported HP eigentlich die Migration der SD DB auf eine Oracle 11g? Irgendwie glaube ich da nicht so dran...

Dir sollte klar sein, dass man manche Sachen nicht hier öffentlich im Board diskutiert.

Zum Beispiel?

Wenn nicht, tut es mir leid und du solltest dann noch einiges Lernen im Leben...

Danke für den Hinweis. Du solltest ihn beherzigen. ;)

Na gut, wenn du das abwürgst bevor es interessant wird. Da ich aus dem Rheinland komme bin ich sicherlich kein Arbeitgeber, ich kenne in dem von dir genannten Raum aber genug Leute die gerade aktiv suchen.

Viel Erfolg bei der weiteren Suche!

Bei XING kratzen die Rekruter wie **** momentan, vielleicht ist das was für dich?

Kann ich bestätigen. Drei bis vier Anfragen in der Woche sind bei entsprechenden Skills kein Problem.

Nach meiner Schulzeit habe ich eine Ausbildung zum Energieanlagenelektroniker erfolgreich absolviert. Im IT-Umfeld arbeite ich seit 1999 ( Betreuung von Privat- und Geschäftskunden, Planung, Durchführung und anschliessende Wartung von IT-Anlagen im SBS-Umfeld (5 - 100 User), Beratung und alles was in diesem Umfeld so anfällt). Als Zertifizierung kann ich den MCP SBS 2003 und den MCTS SBS 2008 vorweisen.

Das ist jetzt alles nicht sooo der Bringer. Wie sieht es mit Knowhow in den Bereichen Server, Storage, Netzwerk, Virtualisierung oder Projektmanagement aus? Wie tief geht das Knowhow jeweils? Wie mobil bist du, sprich: Wie schaut es mit Reisebereitschaft aus? Gehaltsvorstellung? Suchst du wieder einen Job in einem Systemhaus oder aus als Admin?

NTFS ist kein Cluster-Filesystem, dementsprechend geht das nicht. Eine Lösung wäre z.B. Sanbolic Melio FS Clustered File System. Das kostet aber...

a) Du benötigst entweder eine - besser zwei - 10gb Leitungen

Er braucht min. zwei - schon wegen Redundanz. Wenn 10 GbE zu teuer ist, dann tut es auch Multipathing über entsprechend viele NICs. Ich befürchte nur, dass der Filer nur zwei Interfaces hat und die ein VIF bilden.

Was für ein Filer ist das konkret?

b) die NetApp muss dichter an die Server.

Je nach dem ob a) oder b) möglich ist, lässt sich dann Weiteres planen.

Lokalität ist bei Storage nun mal das A und O.

Lesen geht bei RAID 5 wegen dem Striping natürlich fixer. Kannst du dir ja selber ausrechnen. Du hast in jedem Stripe einen Chunk mit Parity.

Große RAID Sets haben den Vorteil des geringen Verschnitts. Haben aber den Nachteil der Ausfallwahrscheinlichkeit. Auf jeden Fall sollte man nicht mehrere logische Laufwerke in einem Array erstellen, da sich dieser IO gegenseitig beeinflussen kann. Bei RAID 5 und SAS Platten finde ich Sets zwischen 6 und 9 Platten für okay. Hängt aber auch vom Speichersystem, der Plattengröße und dem RAID Level ab. Große Arrays resultieren halt in großen logischen Laufwerken und dann riesen Datastores. Ist auch doof...

Ja, mit iSCSI kann man performance Storage Area Networks aufbauen. Aber:

- deine 1 GbE Leitung ist definitiv zu wenig

- der iSCSI Verkehr sollte in einem eigenen VLAN geführt werden

- End-2-End Konfiguration von Jumbo Frames (Hypervisor bis Filer)

- es sollten mehrere Pfade zur LUN vorhanden sein. Multipathing vor "dicker Leitung"

Warum setzt der Kunde 20 Hypervisor für 48 VMs ein???

Wieviele Daten ich verliere, hängt davon ab, wie lange der letzte Snapshot zurückliegt.

Korrekt. Snapshots auf dem Primärspeicher sind eine einfache Variante das RPO zu minimieren.

Auch die Backup2Disk Lösung ist Teil eines Konzepts, genauso wie die Kosten pro TB - die unbestritten bei LTO5 unter denen von SATA HDD liegen.

Zusammen mit den Prioritäten des Kunden ergeben sich dann verschiede mögliche Szenarien mit ihren individuellen Vor- und Nachteilen.

d'accord!

Sprich mit deinem ISP. Evtl. kann er dir zwischen den CE Routern IPSec konfigurieren.

Kommt drauf an... Ich rechnte für eine 15k SAS Disk, ohne Cache o.ä., 200 IOPS (kannst du dir sogar selber ausrechnen... Du brauchst nur Seektime und Rotation Latency). Wenn du 3000 IOPS (write) brauchst, dann hängt es vom RAID Level ab. Bei RAID 1+0 kannst du 50% der IOPS nutzen, bei RAID 5 nur 25%. Dementsprechend brauchst du 30 bzw. 60 Disks. Ist natürlich ohne Caches gerechnet... Pi x Auge x Hackebeil. Und wir haben hier noch nicht über IO Größen gesprochen...

Die heutigen Plattengrößen sind eine Pest. Viele Kunden/ Dienstleister orientieren sich an der Kapazität, nicht an den geforderten IOPS. Nicht umsonst finde ich immer mal wieder virtuelle Serverumgebungen mit viel RAM, verdammt vielen Kernen, 10 GbE... und einer Handvoll Platten. Man sollte sich eher an den notwendigen IOPS orientieren. Ich bin auch immer ein Freund von kleineren und schnelleren Platten. Ist eine Preisfrage. Man muss nicht 10 Semester BWL studiert haben um zu berechnen, ob man lieber 15k Platten nimmt oder entsprechend mehr 10k Platten. Irgendwann gibt es einen Break Even. Da muss man beim Design dann etwas spielen und rechnen. So können, je nach Preisen, 30x 300 GB 15k günstiger sein, als 20x 450 GB SAS 15k. Bei den 300 GB platten habe ich 50% mehr IOPS im Vergleich zu den 450er Platten.

Wenn wir über Virtualisierung reden, dann reden wir über brutalen random IO. Blockbasierter Speicher hat meist eh keine gute Cache Hit Rate, aber bei random IO bzw. Virtualisierung wird es noch schlimmer. Die IO Größe gibt der Gast bzw. die Anwendung vor. Insofern ist es gut, wenn dir dein Speichersystem die durchschnittliche IO Größe ausspuckt. Dann hast du zumindest einen Anhaltspunkt. Natürlich kannst du auch im Gast messen, geht auch.

Guter Hinweis! Das "VPN" bezieht sich auf für euch "reservierte" Pfade durch das Netz des ISP.

Oder schaffe einen Anwendungsfall für DFS:

Ich bin bei einer Servermigration vom absoluten Pfad unabhängig. Alle meine shares stelle ich über einen Domain Namespace bereit. Auch wenn diese jeweils nur ein Ziel haben.

DFS nutzen im Servernamen in UNC Pfaden zu vermeiden ist ein Anwendungsfall für DFS. Korrekt. Bin ich bei dir, mache ich auch gerne so.

DFS Replikation einrichten und im DFS Link nur ein Link Target einrichten, um "last save wins" zu umgehen, ist für mich... mmh... irgendwie eine Perversion von DFS. Mag ja sein das du damit beim Kunden ein Problem umgehst, aber wäre es nicht besser das Problem zu lösen?

Konstruiert? RTO ist nicht alles?

Erzähl das mal einem Vorstand im Einzelhandel, der bei einer Stunde Downtime im Weihnachtsgeschäft einen sechstelligen Betrag verliert.

RTO ist nicht alles. Ein Restore innerhalb von Sekunden bringt mir nichts, wenn ich Daten von einem Tag verliere.

Ich rede über Konzepte. Du über Diskbackup.

Kannst du aus dem ACU mal einen Array Diagnostic Report ziehen und hier anhängen?

Bei VDI brauchst du weder viele MB/s, noch brauchst du viele IOPS. Ein virtueller Desktop kommt mit relativ wenig Leistung aus.

Ein Sizing aus dem Bauch heraus ist schwer. Grundsätzlich brauchst du, wenn du IOPS haben willst, vor allem eines: Platten, Platten, Platten... schnelle Platten. Wenn du dann MB/s haben willst, dann brauchst du große IOs.

Einfaches Beispiel: Exchange bis Exchange 2003 nutzt 4 KB IOs. Wenn ich z.B. aus einem System 4000 IOPS gezogen habe, dann bin ich gerade mal auf ca. 16 MB/s gekommen. Arbeite ich z.B. mit großen Files, die ich in großen IOs lese (z.B. 256 KB), dann komme ich ebi 4000 IOPS schon auf knapp 1000 MB/s.

Als low oder no budget Lösung wäre folgendes denkabr: Die Ordner zwischen den Servern per DFS replizieren.

Einen Domain Namespace erstellen und nur ein Ziel einrichten.

Beim Ausfall könnte dann der Zielpfad manuell auf den noch funktionierenden Server umgelegt werden.

Damit pervertiere ich doch die Vorteile von DFS?!?!?!

Warum willst du zwei Fileserver mit identischem Inhalt am selben Standort betreiben und dir den ganzen Verwaltungs-Overhead ans Bein binden?

DFS Replikation und DFS Targets mit mehreren DFS Target Links sind der zentrale Vorteil von DFS. Mehr Verfügbarkeit, Lastverteiltung, verteilte Umgebungen.

Das Problem ergibt sich schon bei einem DFS Link mit zwei Link Targets. Last save wins gilt immer noch in 2008 R2, distributed Locking gibt es nicht.

Wenn last save wins für mich ein Problem ist, dann versuche ich entweder etwas in einem DFS zu betreiben, was da besser nicht sein sollte (z.B. Anwendungen) oder ich sollte mir Gedanken über ein ECM machen.