Hallo, ich verstehe nicht ganz die Funktionalität von virtuellen Festplatten. Ich habe eine SQL Datenbank diese soll eigentlich immer auf einer eigenständigen Festplatte laufen. Heißt das: A ich binde eine physikalische Festplatte für die VM ein? oder B kann ich auch eine zweite virtuelle Festplatte einbinden? Danke
Apfel schrieb: > Ich habe eine SQL Datenbank diese soll eigentlich immer auf einer > eigenständigen Festplatte laufen. Sagt wer? Obacht: Manche bezeichnen D: als Festplatte, egal wo und worauf es liegt, verwechseln das also mit einem Filesystem. Ich würde es mal so formulieren: Eine intensiv genutzte Datenbank, die auf einer HDD platziert wird, sollte wenns geht nicht zusammen mit anderen intensiv auf Disk zugreifenden Anwendungen auf der gleichen HDD landen. Wenn die VM aber eine VDisk auf SSD verwendet, kannst du solche Tips von anno dunnemal getrost ignorieren.
:
Bearbeitet durch User
Kommt auf die Datenbank an, die gibt es von klein bis riesig. Eine große, produktive Datenbank würde ich ohnehin niemals in einer VM laufen lassen, weil die VM leicht selbst ein Flaschenhals werden kann. Von Ausfallsicherheit und Managementproblemen ganz zu schweigen... Natürlich kann eine VM auch mehrere vDisks haben, die auch als virtuelles RAID konfiguriert sein können. Manche Hostsysteme können auch dedizierte Hardware an die VMs "durchreichen", z.B. Netzwerkkarten oder auch Laufwerke. Das ist allerdings immer von vielen Faktoren abhängig, u.a. OS, Treiber, Hardware und nicht zuletzt der Virtualisierungssoftware selbst. Wenn die Datenbank langfristig gebraucht wird, dann würde ich von Virtualisierungen stark abraten, zumal die ganze Software meistens mehr kostet als ein zusätzlicher physischer Server. Für Testumgebungen oder kleine, wenig belastete Systeme (die aus welchen Gründen auch immer getrennt werden sollen) hingegen ist die Virtualisierung ideal.
Eine virtuelle Festplatte ist nichts weiter als eine Datei, die wiederum auf einem physischen Laufwerk des VM-Hostes liegt. Auf welchem Hostlaufwerk, läßt sich i.d.R. frei konfigurieren oder später auch verschieben, der virtuelle Server bekommt davon nichts mit. Es kann durchaus Sinn machen, die virtuellen Platten auf verschiedene physische Hostlaufwerke zu legen, wenn die virtuellen Server sehr plattenlastig arbeiten. Wie A.K. schon richtig bemerkt hat, spielen die Zugriffszeiten bei SSDs kaum eine Rolle, aber bei klassischen HDDs sieht das anders aus. Und wenn häufig sehr große Dateien bewegt werden müssen, rückt auch die Dauertransferrate ins Licht. Das Ganze ist extrem verwendungsabhängig, Pauschaltips sind eher schwierig.
svensson schrieb: > zuletzt der Virtualisierungssoftware selbst. Er sprach doch explizit von Hyper-V. Und ja, das kann auch komplette physikalische Laufwerke in den Gast reinreichen, was bei einer DB aus Performancegründen durchaus sinnvoll sein kann. Für große DBs würde sich eventuell sogar SAN anbieten.
svensson schrieb: > Eine große, produktive Datenbank würde ich ohnehin niemals in einer VM > laufen lassen, weil die VM leicht selbst ein Flaschenhals werden kann. > Von Ausfallsicherheit und Managementproblemen ganz zu schweigen... Was ist für dich "gross"? Zudem sind "gross" und "hoch belastet" unabhängige Parameter. Ausfallsicherheit und Management kann in VMs einfacher implementiert sein, als direkt auf realer Hardware. > Wenn die Datenbank langfristig gebraucht wird, dann würde ich von > Virtualisierungen stark abraten, zumal die ganze Software meistens mehr > kostet als ein zusätzlicher physischer Server. Man sollte die Gesamtsituation betrachten. Hat man hunderte von VMs auf einer Handvoll Virtualisierungshosts laufen, mit VDisks auf NAS/SAN? Oder geht es um 2 Server insgesamt, mit lokalen Disks? Wir haben mittlerweile sämtliche selbst gehosteten DBs auf einem zentralen hochverfügbaren Storage-System und sämtliche DB-Server in der Virtualisierung. Teils über VDisks auf NFS, teils über NFS direkt.
:
Bearbeitet durch User
svensson schrieb: > Eine große, produktive Datenbank würde ich ohnehin niemals in einer VM > laufen lassen, weil die VM leicht selbst ein Flaschenhals werden kann. Virtualisierung ist Stand der Technik und funktioniert mittlerweile sehr stabil und performant. Ich habe gerade erst ein konventionelles System aus mehreren (Blech-)Servern (1x DC/Fileserver, 1x SQL-Server, 4x Terminalserver) virtualisiert. Jetzt läuft alles auf einem einzigen physischen Server, ohne Performanceeinbußen. Im Gegenteil, die gefühlte Arbeitsgeschwindigkeit hat sich sogar verbessert, wozu die SSDs für System und Programme sicher beitragen. Als Datengrab dient aus Kostengründen ein RAID10 aus 8 klassischen HDDs. > Von Ausfallsicherheit und Managementproblemen ganz zu schweigen... Das ist eher ein Argument PRO Virtualisierung. Redundanz läßt sich wesentlicher einfacher realisieren und das Management erst recht. Mal schnell einen (virtuellen) Server sichern? Einfach die virtuellen Festplatten irgendwohin kopieren. Geht problemlos auch per Fernwartung. Keine Turnschuhadministration mit Imaging-Software oder Streß mit RAID-Controllern mehr. Hardwaretausch nötig? Virtuelle Maschinen und Platten sichern, Host neu aufsetzen, alles zurückkopieren, fertig. Kein Streß mit nicht booten wollenden Maschinen oder Treiberinstallationen. > Wenn die Datenbank langfristig gebraucht wird, dann würde ich von > Virtualisierungen stark abraten, zumal die ganze Software meistens mehr > kostet als ein zusätzlicher physischer Server. Siehe vorstehend, Performanceprobleme sind nicht zu befürchten. Und Kosten auch nicht. Hyper-V ist Bestandteil jeder Standard Windows-Server Lizenz. Mit einer einzigen Lizenz dürfen sowohl der Host als auch zwei virtuelle Server betrieben werden. Und eine weitere Lizenz kostet nicht mehr als ein Desktop-Rechner.
Apfel schrieb: > Ich habe eine SQL Datenbank diese soll eigentlich immer auf einer > eigenständigen Festplatte laufen. Immer sinnvoll: Produktive potentiell wachsende Daten mitsamt ihrer Temp- und Logfiles sollten auf einem separaten Filesystem liegen. Also in Windows sowas wie C: fürs System und D: (oder mehr) für die Daten. Weil voll laufende Daten dann nicht zum Problem für die Wartung vom System werden.
A. K. schrieb: > Immer sinnvoll: Produktive potentiell wachsende Daten mitsamt ihrer > Temp- und Logfiles sollten auf einem separaten Filesystem liegen. Also > in Windows sowas wie C: fürs System und D: (oder mehr) für die Daten. Und das Ganze natürlich auch auf getrennten virtuellen Festplatten, nicht etwa als Partitonen auf einer.
Ich habe nur meine Erfahrungen wiedergegeben. Zu Zeiten des Virtualisierungshype habe ich auch mit Servern gearbeitet, deren Datenfestplatten im SAN lagen. Sogar Systeme mit virtuellen Bootplatten waren geplant. Alle nur 1HE hoch. Es wurde damals sogar von oben vorgeschlagen, die DC zu virtualisieren, wovon selbst M$ abgeraten hat. Ausfallsicherheit, Hochverfügbarkeit, Cluster. Alles schön und gut, jedenfalls solange bis der berühmte Murphy den single-point-of-failure gefunden hat, dann gibt es aber lange Gesichter. Jedenfalls bin ich wieder zurück zu ganz stinknormaler Hardware von der Stange mit ganz stinknormalen RAID-Controllern und handelüblichen Festplatten. Sind natürlich immer noch CTO, aber aus lauter handelsüblichen Komponenten, die ggf. auch nachbeschaffbar sind. Vielleicht werde ich aber auch langsam alt...
Das wird sicherlich kein zentrales Argument von Virtualisierung sein, aber angenehm ist es: Ein virtueller Linux-Server legt in 20 Sekunden einen vollständigen Reboot hin. Der Virtualisierungshost selbst braucht dafür 5 Minuten, die meiste Zeit geht in Selbsttests und Firmware von I/O-Modulen drauf. Das erspart so manche Überstunde. Etliche VM kann ich bei dieser kurzen Unterbrechung zu günstigen Zeiten tagsüber aktualisieren, ohne dass es gross auffällt. Um den Host selbst zu aktualisieren, schiebe ich seine VMs unterbrechungsfrei auf seine Kollegen und habe ihn dann frei.
svensson schrieb: > die DC zu virtualisieren, wovon selbst M$ abgeraten hat. Ja, aber das ist Vergangenheit. Heute kein Problem mehr. Einer der AD-Server liegt bei uns nur deshalb direkt auf übrig gebliebener alter Hardware, damit man im Extremfall kein Münchhausen sein muss. Bei AD/DNS und DHCP wärs besser, wenn man vorneweg rankommt. Wir werden diese redundanten Sekundärserver aber wahrscheinlich auf einen separaten und voll selbständigen kleinen Virtualierungshost konzentrieren. > jedenfalls solange bis der berühmte Murphy den single-point-of-failure > gefunden hat, dann gibt es aber lange Gesichter. Mit Virtualisierung löst man die Verfügbarkeitsfrage einmal, indem man Virtualisierungsplattform bis runter zu Storage und Netzwerk entsprechend auslegt. Ohne Virtualisierung löst man sie für jeden Server erneut, und möglicherweise bei jedem auf andere Art. Ist natürlich eine Frage der Grösse der Umgebung.
:
Bearbeitet durch User
> Wir werden diese Funktionen aber wahrscheinlich auf einen separaten und > voll selbständigen Virtualierungshost konzentrieren. Die Ironie in diesem Satz bleibt Dir hoffentlich nicht verborgen... Da kann man eben auch gleich einen physischen Server nehmen, bei dem die Komplexität mit der Virtualisierung entfällt. Und ich würde gerne sehen, wie die 50 TB eines Fileservers schnell von einer VM zur anderen transferiert werden. > Mit Virtualisierung löst man die Verfügbarkeitsfrage einmal, indem man > Virtualisierungsplattform bis runter zu Storage und Netzwerk > entsprechend auslegt. Klingt nach Consultant, da ist immer alles kein Problem. > Ist natürlich eine Frage der Grösse der Umgebung. Und vor allem eine Frage des Geldes.
svensson schrieb: >> Wir werden diese Funktionen aber wahrscheinlich auf einen separaten und >> voll selbständigen Virtualierungshost konzentrieren. > Die Ironie in diesem Satz bleibt Dir hoffentlich nicht verborgen... Wenn man mehrere ADCs und DHCPs hat, und jeweils einer davon auf Blech liegt, kann man dieses Blech auf einen separaten Virtualisierungshost mit lokalen Disks legen, ohne dass die Verfügbarkeit zu riskieren. Wichtig ist dabei nur, dass dieser Host unabhängig von NAS und der übrigen VMware-Infrastruktur ist. > Da kann man eben auch gleich einen physischen Server nehmen, bei dem die > Komplexität mit der Virtualisierung entfällt. Wenn es bei einem einzigen bleibt... > Und ich würde gerne sehen, wie die 50 TB eines Fileservers schnell von > einer VM zur anderen transferiert werden. Der Fileserver ist ein hochverfügbares NAS, das sich redundant auf 2 getrennte Gebäude verteilt. Als Fileserver wird er direkt verwendet, die VDisks der VMs liegen dort via NFS. Crasht ein Virtualisierungshost, werden dessen kritische VMs automatisch auf den anderen Hosts neu gestartet. Verschoben wird für Wartung eines Hosts nur der laufende Kontext einer VM, nicht deren Disks, so dass es bei einer laufenden VM je nach Aktivität nur Sekunden bis wenige Minuten dauert und dabei vom Anwender nicht bemerkt wird. Solche Migration findet zwecks Load Balancing auch automatisch im Normalbetrieb statt. > Klingt nach Consultant, da ist immer alles kein Problem. Bin Anwender seit VMware ESXi 1.5 >> Ist natürlich eine Frage der Grösse der Umgebung. > > Und vor allem eine Frage des Geldes. Grösse und Geld gehen Hand in Hand. Neben Beschaffungs- und Wartungskosten spielen aber auch Gehälter eine Rolle. Virtualisierung spart Admins. In grösseren Umgebungen ist das günstiger als hunderte Server in Blech. Zudem spielt natürlich auch eine Rolle, mit welcher Ausfallzeit man leben kann. Wenn einem Bäcker abends zentrale Geräte abrauchen und sämtliche Filialen tags drauf nix zum beissen anbieten können, fällt das unangenehm auf. Stellt man Streichhölzer her, kann man das gelassener angehen.
:
Bearbeitet durch User
svensson schrieb: > Ausfallsicherheit, Hochverfügbarkeit, Cluster. Alles schön und gut, > jedenfalls solange bis der berühmte Murphy den single-point-of-failure > gefunden hat, dann gibt es aber lange Gesichter. Man kann die Systeme durchaus vollständig redundant auslegen, sodaß der Ausfall einer beliebigen Komponente nicht zur Beinträchtigung des laufenden Betriebes führt. Ja, das kostet Geld und ja, das kostet Hirnschmalz. Deswegen wird es nur in Umgebungen gemacht, wo Hochverfügbarkeit wirtschaftlicher ist als die Inkaufnahme von Ausfallzeiten. Alle anderen Systeme haben ganz zwangsläufig SPOFs. In einer virtualisierten Umgebung streikt die Hardware des VM-Hostes, System fällt aus. In einer konventionellen, nicht redundanten Umgebung streikt der Domänencontroller, System fällt aus. Der Datenbankserver streikt, alle darauf basierenden Anwendungen fallen aus (geht also nicht mehr viel außer im Internet surfen). Der Terminalserver streikt, System fällt aus, außer man hat mehrere TS. Macht für die Verfügbarkeit also keinen Unterschied, ob virtualisiert oder Blech. Interessant wird es bei der Wiederherstellung des Systems. Habe ich Carepacks für die Serverhardware, rufe ich beim Support an und die kümmern sich um die Reparatur. Habe ich keine Carepacks, muß ich bei klassischem Blech entweder Ersatzteile vorhalten oder diese kurzfristig beschaffen können. Letzteres kann schon nach wenigen Jahren zum Problem werden. Besorg mal Ersatz für ein drei Jahre altes Servermainboard. Inzwischen haben sich die CPU-Sockel geändert und meist sind auch die RAM-Module nicht kompatibel. Du mußt also neuere Hardware verbauen, die andere Treiber erfordert und hast oft Streß, den Server wieder zum Hochfahren zu überreden (ja, ich kenne das). Hast du obendrein keine Baremetal-Sicherung und es geht richtig schief, dann gute Nacht. Mit virtualisierten Servern ist neue Hardware völlig unkritisch. Lediglich der Host muß installiert werden, das dauert im Normalfall keine Stunde. Danach die VMs wieder drauf und los gehts. Im Extremfall kann ich sogar einen Notbetrieb auf Desktophardware improvisieren. Die technischen Vorteile der Virtualisierung überwiegen ganz klar. Und sie spart noch dazu Kosten. Denn ich brauche sowohl weniger physische Maschinen als auch weniger Lizenzen, denn auf Blech benötigst du für jeden Server eine separate Lizenz, bei VMs genügt eine für zwei virtuelle Server. Mir fällt echt kein Argument ein, weshalb man heutzutage nicht virtualisieren sollte.
> In einer konventionellen, nicht redundanten Umgebung streikt der > Domänencontroller, System fällt aus. Falsch DC, DHCP und DNS existieren redundant als physische Maschinen. Ja, einzelne Dienste können ausfallen, aber die meisten bleiben funktionsfähig. Und die HPC-Server zu virtualisieren wäre völlig absurd. > Ersatzteile vorhalten oder diese kurzfristig beschaffen können Genau deshalb habe ich z.B. die Festplatten lagernd. Gerade habe ich vier Maschinen ausgemustert, die satte 10 Jahre in Betrieb waren - okay, die meisten Platten waren nicht so alt. > Mit virtualisierten Servern ist neue Hardware völlig unkritisch. Und dann ist die neue Hardware plötzlich nicht mehr für die alten Versionen zertifiziert (oder es fehlen gar Treiber) und für die neuen braucht man neue Lizenzen, die dann aber leider die alten OS nicht mehr unterstützen. Auch hier gibt es viele Fallstricke. > Und sie spart noch dazu Kosten. Was zu beweisen wäre. Meist ist die "ausfallsichere Hardware" deutlich teurer als zwei Standardgeräte. Lizenzen bekomme ich umsonst, das ist kein Argument. Wenn womöglich noch "Externe" eingekauft werden müssen, dann wird das richtig teuer.
svensson schrieb: > Falsch DC, DHCP und DNS existieren redundant als physische Maschinen. Natürlich kann man auch in virtualisierter Umgebung noch einen physischen Backup-DC integrieren. Da sind wir aber schon auf dem Weg Richtung Redundanz. > Ja, einzelne Dienste können ausfallen, aber die meisten bleiben > funktionsfähig. Bei den meisten meiner Kunden bewirkt schon der Ausfall nur eines wichtigen Servers annähernde Arbeitsunfähigkeit. Ohne Fileserver keinen Zugriff auf Userprofile und allgemeine Daten, ohne Datenbankserver keine Arbeit mit der Branchensoftware und ohne Terminalserver auch nicht. Mit einem Backup-DC können sich die Leute noch anmelden, es nützt ihnen aber nichts. > Genau deshalb habe ich z.B. die Festplatten lagernd. Festplatten sind nicht das Thema, da leicht beschaffbar. Größer als die alte geht immer. Aber hast du auch Mainboards, Speicherriegel und Controller auf Lager? > Und dann ist die neue Hardware plötzlich nicht mehr für die alten > Versionen zertifiziert (oder es fehlen gar Treiber) Der Supportzeitraum für Betriebssysteme ist i.d.R. wesentlich länger als der Produktlebenszyklus von Hardware. CPU- und Mainboardgenerationen werden gewöhnlich nach 2-3 Jahren obsolet und baugleiche Mainboards sind oft schon nach wenigen Monaten nicht mehr erhältlich. Für Windows Betriebssysteme läuft die Unterstützung mindestens 5 Jahre, praktisch eher 10 Jahre. Für die virtuellen Maschinen spielt es außerdem keine Rolle, auf welcher Hardware und unter welchem OS der Hypervisor läuft, solange er die gleiche virtuelle Umgebung emuliert. > Auch hier gibt es viele Fallstricke. Nicht wirklich viele. Auf jeden Fall um Größenordnungen weniger als bei physischen Maschinen. > Was zu beweisen wäre. Meist ist die "ausfallsichere Hardware" deutlich > teurer als zwei Standardgeräte. Was ist ausfallsicher? Redundante Netzteile und Festplatten sollten bei Servern selbstverständlich sein, alles andere ist ohnehin nur einmal da. Natürlich kommt ein fetter, als VM-Host geeigneter Server teurer als ein anwendungsspezifischer und weniger leistungsfähiger. Aber bei rein physischer Struktur brauchst du eben für jeden Server ein eigenes Blech. Und die werden in der Summe wieder teurer als der dicke Brummer. > Lizenzen bekomme ich umsonst, das ist kein Argument. Das ist für dich kein Argument, für den normalen Anwender schon. Siehe meinen oben beschriebenen Praxisfall. Für 6 physische Server müßte ich 6 Lizenzen kaufen. Bei einem physischen Gerät und 6 VMs brauche ich nur drei. Ergibt eine Ersparnis von fast 2000€ allein bei den Lizenzen. > Wenn womöglich noch "Externe" eingekauft werden müssen, > dann wird das richtig teuer. Firmen ohne eigenen Admin müssen das unabhängig von der Struktur sowieso. Die Zeiten, wo ein Mitarbeiter, "der was von Computern versteht", das System nebenbei administrieren konnte, sind schon lange vorbei. Da Virtualisierung den Administrationsaufwand verringert, ergibt sich auch hier Kostenreduzierung.
Icke ®. schrieb: > Natürlich kommt ein fetter, als VM-Host geeigneter Server teurer als ein > anwendungsspezifischer und weniger leistungsfähiger. Aber bei rein > physischer Struktur brauchst du eben für jeden Server ein eigenes Blech. > Und die werden in der Summe wieder teurer als der dicke Brummer. Heutige Prozessoren sind sehr oft wesentlich leistungsfähiger als einzelne Server benötigen. Ob ADC oder DHCP auf 2 Cores oder 4 läuft merkt niemand, weshalb man auf einem Minimal-Host mit 4 Cores - kleiner gibts schon lange nicht mehr - etliche VMs betreiben kann. Dicker wird nur das RAM. Wenn alle VMs einer nicht-trivialen Umgebung einzeln als Blech implementiert werden, dann steckt sehr viel mehr Geld drin als in einem diese Umgebung abdeckenden Virtualisierungshost (*). Jedes Stück Blech hat dann mindestens 4 sich meist langweilende Cores, 3 Netzwerkanschlüsse (1x Management, 2x Anbindung), 2 Netzteile, genug Switches für die Netzwerk-Anschlüsse, Racks fürs Blech, Platz für die Racks, dicke Kabelbündel und Patchpanels, ... Der Virtualisierungshost dafür hat 1-2 HEs, keine Bootdisk (µSD oder USB-Stick), 3-5x Netzwerk, dafür aber genug RAM. Als ich das letzte mal nachsah, kriegte man in einen normalen 1 HE Server 1,5 TB RAM rein. Als einzelnen Server kriegt man heute wohl kaum etwas unter 8 GB, ob man die braucht oder nicht. Dem DHCP-Server reichen aber 2 GB locker aus. Somit ist auch die Summe an RAM virtualisiert geringer als in Blech, noch völlig ohne Deduplication von RAM und Paging auf Hypervisor-Ebene gerechnet. *: Betriebssystem-Kosten auch. Mit Windows als Datacenter-Edition sind alle VMs eines Hosts abgedeckt, und bei Linuxen wie Redhat oder Suse sieht es ähnlich aus. Nur Oracle sollte man grossräumig umfahren, deren Lizenzierung ist einfach nur grotesk.
:
Bearbeitet durch User
> Hardware In den letzten 10 Jahren hatte ich nur Festplatten (davon aber reichlich), Netzteile und Lüfter als Ausfälle.* NT+Lüfter bekomme ich am nächsten Tag. Die Festplatten haben ohnehin 5 Jahre Garantie, d.h. die lagernden werden eingesetzt und die Austauschplatten kommen am nächsten Tag. Und natürlich laufen AD, DHCP und DNS zusammen auf jeweils einer physischen Maschine. Da sind dann auch noch die PS und die /homes, damit sich die Maschinen nicht zu sehr langweilen. Trotzdem bleibe ich bei etwa 20 physikalischen Servern. > Jedes Stück Blech hat dann mindestens 4 sich meist langweilende Cores Die HPC haben bis zu 40 Cores. > 3 Netzwerkanschlüsse (1x Management, 2x Anbindung) Na und? Die kosten doch nichts, weil auf dem Mainboard enthalten. Wohingegen eine 4-Port-ESX-fähige schon einmal 1000 Euro kosten kann. > 2 Netzteile Zwei Netzteile und zwei Strompfade sind bei uns ohnehin Standard. > genug Switches für die Netzwerk-Anschlüsse, Racks fürs Blech, > Platz für die Racks Der Serverraum ist ohnehin vorhanden. Und ein managebarer Switch pro Rack ist selbst von CISCO aus der Portokasse bezahlbar. Und ein/zwei Kabel pro Server ist noch kein Kabelbündel... > Firmen ohne eigenen Admin müssen das unabhängig von der Struktur sowieso. Ja, aber der "Virtualisierungsexperte" ist eben teurer als der normale Admin. Und wenn dann alle drei Jahre die teure Hardware erneuert werden muß, weil ja kein Support mehr da ist und alle Dienste auf einer Maschine vereint zu gefählich sind, dann landet die ganze Matsche schließlich in der Cloud -> Admin überflüssig. * Nur im SAN ist ein Mainboard kaputtgegangen, das dann wochenlang um den Globus unterwegs war = da standen dann die virtualisierten Maschinen.
svensson schrieb: >> 3 Netzwerkanschlüsse (1x Management, 2x Anbindung) > Na und? Die kosten doch nichts, weil auf dem Mainboard enthalten. Auf der Server-Seite nicht. Dafür aber auf der anderen Seite, also in Form von Switch-Ports und Verkabelung. Das läppert sich. > Wohingegen eine 4-Port-ESX-fähige schon einmal 1000 Euro kosten kann. Wenn man unterhalb der oben beschriebenen Enterprise-Umgebung in der Zentrale bleibt, reicht das aus, was der Server mitliefert. In Aussenstellen steckt die kleinste Kiste, die damals verfügbar war: 4 gelangweilte Cores und von 3 Ethernets onboard werden nur 2 genutzt. Die in der Zentrale sind etwas besser ausgerüstet, aber wenn du einige hundert aktive VMs auf einer Handvoll Hosts laufen lässt, sind auch die Kosten für 2x 10Gb Ethernet pro Host drin. > Der Serverraum ist ohnehin vorhanden. Einer davon wurde vor ein paar Jahren halbiert, weil Platz knapp und dank Virtualisierung und zentralem Storage halb leer. > Und ein managebarer Switch pro > Rack ist selbst von CISCO aus der Portokasse bezahlbar. Und ein/zwei > Kabel pro Server ist noch kein Kabelbündel... Bei einigen hundert Servern? > Und wenn dann alle drei Jahre die teure Hardware erneuert werden > muß, weil ja kein Support mehr da ist Gekauft mit 5 Jahren Support. Es gibt Firmen, die Hardware-Service darüber hinaus anbieten und das nutzen wir auch. Die älteren der zentralen Hosts haben CPUs von 2012. Dem geplanten Ersatz kam Spectre in die Quere, statt dessen kamen 2 in anderer Rolle ausgemusterte Altserver hinzu. Bei den Servern der Aussenstellen lebte die letzte Generation 10 Jahre. Bei zweistelliger Anzahl hat man dann eben Reserve im Lager. Ersatzteile und Erweiterungskomponenten für ältere Server gibts günstig bei Ebay und anderen Leichenfledderern, wenn nicht zu exotisch. Haben wir auch schon öfter genutzt. > Maschine vereint zu gefählich sind, dann landet die ganze Matsche > schließlich in der Cloud -> Admin überflüssig. Yep. Kenne ich aus anderer Firma gleicher Branche und Grössenordnung. Wer braucht schon immer Festnetztelefonie (ist in der Cloud), notfalls wird halt gemailt oder gechattet. Und für den Fall, dass das auch in der Cloud ist gibts Mobiltelefone. Zum fairen Ausgleich ist das teuer als bei uns und wird mit grösserer Mannschaft betrieben. ;-) > * Nur im SAN ist ein Mainboard kaputtgegangen, das dann wochenlang um > den Globus unterwegs war = da standen dann die virtualisierten > Maschinen. Wie Icke schon beschrieb: Wenn Host FUBAR und es ist eilig, dann nimmt man einen anderen. Muss nicht identische Hardware sein. Egal ob Intel oder AMD, nur bei der Live-Migration ist das wichtig.
:
Bearbeitet durch User
svensson schrieb: > Ja, aber der "Virtualisierungsexperte" ist eben teurer als der normale > Admin. Kann ich nicht bestätigen. Ob ich ein AD auf einem physischen oder virtuellen Server aufsetze, nimmt sich vom Anspruch her nichts. Den Hypervisor zu installieren und die VMs anzulegen, ist jetzt auch nicht sooo kompliziert. Wer in der Lage ist, Netzwerke auf physischer Struktur zu administrieren, wird auch kein Problem damit haben, sich das für Virtualisierung nötige Zusatzwissen nebenbei autodidaktisch anzueignen. Jedenfalls sind die Stundensätze bei mir die gleichen, egal ob physisch oder virtuell. > Und wenn dann alle drei Jahre die teure Hardware erneuert werden > muß, weil ja kein Support mehr da ist und alle Dienste auf einer > Maschine vereint zu gefählich sind, dann landet die ganze Matsche > schließlich in der Cloud -> Admin überflüssig. Wenn aus Kostengründen Dienste in die Cloud verlagert werden, ist bestimmt nicht die Virtualisierung schuld. Denn die ist im Endeffekt billiger als eine Blechfarm. Allerdings könnten sich Admins, die nicht mit der Zeit gehen, entbehrlich machen ;-)
> aber wenn du einige hundert aktive VMs auf einer Handvoll Hosts laufen > lässt Da liegt der Hund begraben. Ich rede von 20 Servern und Du von hunderten. > Switch-Ports und Verkabelung Switchports kosten fast nichts, bei unseren Geräten im Rack etwa 10 Euro pro Port. Selbst der Core-Switch kostete nur 3.500 Euro bei 50 Ports. Kabel kosten unter 3 Euro, da ist fast schon die Beschriftung teurer als das Kabel selbst. > sind auch 2x 10Gb Ethernet drin. Bekam ich leider nicht genehmigt, da man Angst vor Folgekosten hatte: "Nachher wollen Sie noch einen Außenanschluß mit 10 Gigabit..." > Administration Damit meine ich jetzt nicht eine VM anzulegen und dort Win2012 zu installieren (einen VM-Server haben wir auch mit derzeit 4 VMs auf Linux), sondern das ganze Storage auszulegen. Unsere 175 Festplatten passen halt nicht in ein Home-NAS. PS: Cloud ist bei uns verboten.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.