Inhouse Server oder Cloud

[thetank7]

Moin zusammen,

ich bin .NET Softwareentwickler in einem kleinen Unternehmen (3 Mitarbeiter) und stehe gerade vor der Frage, ob es sinnvoll ist weiterhin einen Server bei uns inhouse zu betreiben.

Das aktuelle Setup sieht in etwa so aus:

• Windows Server 2016
• Intel Xeon X5550
• 48GB RAM
• Adaptec 51645 RAID-Controller
• 4 x 1TB SSD - RAID 5
• 12 x 500GB HDD - RAID 5
• 19" Gehäuse in 19" Rack mit etwa 15-16 HE (es ist nur das Gehäuse im Rack..)
• USV
• unfassbar laut, sehr viel Abwärme
• ca. 12 Jahre alt
• Backup auf externe HDD via USB

Was dort zur Zeit in jeweils eigenen VMs läuft:

• AD & DNS (2GB RAM, 200 GB HDD)
• SQL Server (8 Cores, 8GB RAM, 1TB SSD Speicher, ca. 70 Datenbanken, nur Entwicklung/Test)
• IIS (2GB RAM, ca. 150GB SSD, nur Entwicklung/Test)
• TFS / Azure DevOps (6GB RAM, 300 GB SSD)
• Fileserver (3GB RAM, 1.1 TB HDD)
• diverse nur sporadisch laufende VMs mit verschiedensten Windows Versionen für Testfälle, etwa 600GB HDD Speicher
• Es lief dort sogar mal ein Exchange Server, welcher aber zum Glück durch Exchange Online abgelöst wurde.

Was dort nicht läuft:
- VPN Server, Zugriff wird aktuell über eine Fritz!Box geregelt

Stein des Anstoßes ist in erster Linie, dass wir uns räumlich etwas verändern (weniger Fläche, mehr Home Office) und zukünftig keinen Serverraum mehr haben wollen und können (eigentlich ein unglaublicher Luxus bei dieser Mitarbeiterzahl). Mit dem aktuellen Server kann jedoch niemand in einem Raum zusammenarbeiten. Zudem wird der Server in den letzten 3-4 Jahren nur noch stiefmütterlich behandelt, da der Mitarbeit, der den Server ursprünglich betreute, seitdem nicht mehr da ist und der Aufgabenbereich nicht neu vergeben wurde (nicht meine Verantwortung). Es war somit auch unser Glück, dass keine größeren Probleme angefallen sind. Zudem sehe ich so ein Monster einfach als viel zu überdimensioniert für unsere Zwecke. Ich kenne den Stromverbrauch nicht und ehrlich gesagt möchte ich ihn auch nicht kennen, aber es würde mich wundern, wenn die Kiste im Schnitt mit 200W auskommt.

Aus meiner Sicht gibt es eigentlich nur zwei Möglichkeiten:

1) Wir verlagern alle diese Punkte in die Cloud. Einige Punkte wären sogar kostenfrei wie Azure DevOps, andere relativ kostengünstig zu haben. Schwierig oder auch teuer würde uns der SQL Server zu stehen kommen und evtl. auch die nur selten genutzten diversen Test VMs.

2) Anschaffung eines neuen Servers. Hierzu muss ich allerdings sagen, dass ich das nicht als mein Fachgebiet bezeichnen würde und ich mir einiges erst aneignen müsste, wenn ich das übernehme. Dementsprechend habe ich auch keine Vorstellung davon, wie viel Zeit mir dafür verlorengehen würde. Von der Zusammenstellung her würde ich an folgendes denken:

• Tower Gehäuse, vlt schallgedämmt
• Ryzen 5 5600
• 32 GB ECC RAM
• günstiges B550 Board
• 4 x 2TB SSD im onboard RAID 1

Ziel soll es sein möglichst wenig Arbeit mit der Infrastruktur zu haben, damit wir uns auf unsere eigentliche Arbeit konzentrieren können. Auf der anderen Seite sollten die Kosten dafür aber auch nicht aus dem Ruder laufen.

Was meinen die Experten dazu? Ich habe kein Problem mit ehrlichen Antworten. Also falls etwas völlig bescheuert sein sollte, könnt ihr das auch gerne so benennen. Datentechnisch sind für uns nur die Punkte Fileserver und Azure DevOps so wichtig, dass dort nichts verlorengehen darf. Der Rest ist nur für Entwicklungs-/Testzwecke und kann (natürlich mit etwas Aufwand) wieder hergestellt werden.

 

[visiothek]

Hallo, welche Internet Anbindung/ Geschwindigkeit habt ihr?

 

[cloudman]

Schwierig eine pauschale Antwort zu geben.

Pro Cloud: die Mitarbeiter im Home Office können auf die Cloud Server sicher besser zugreifen als über VPN wenn ihr nicht eine sehr gute Anbindung habt.
Wenig Aufwand mit der Infrastruktur.
Keine neue Investition notwendig.
Daten werden wenn man will mehrfach redundant gespeichert

Contra Cloud :
Bei deinem Einsatzszenario fallen mir nur die möglichen Kosten ein. Gerade VMs werden gerne mal vergessen wenn man sie nicht mehr braucht.
Kostenkontrolle ist hier essentiell.


Ein genauer Vergleich ist schwierig wenn man nicht weiß wieviel die eigene Infrastruktur kosten und wie groß die Cloud Rechnung wird.
Ich persönlich würde die Neuanschaffung erstmal lassen und 2 Monate Cloud testen. Dann kann man bestimmte Dienste vielleicht dort lassen und andere Inhouse betreiben

 

[thetank7]

Hallo, welche Internet Anbindung/ Geschwindigkeit habt ihr?

Aktuell 100/40 Mbit (Telekom VDSL). Zukünftig steht noch nicht fest, sollte aber mindestens da liegen.

Alternativer Standort für den Server könnte aber auch bei mir zu Hause sein, habe dort seit kurzem 1 Gbit symmetrisch (Glasfaser).

 

[derchris]

IaaS, PaaS, SaaS ... wenn es kein eigener SQL Server sein muss, dann einfach eine paar Datenbank-Instanzen ... Muss es ein Fileserver sein? Sharepoint/Teams/OneDrive gibt es auch noch ...

Cloud klingt gut. Ausgeschaltet VMs kosten in der Regel nicht viel, vielleicht ein bisschen für den Storage.
Reporting und Costcontroll nicht vergessen.

 

[Millkaa]

Alternativer Standort für den Server könnte aber auch bei mir zu Hause sein, habe dort seit kurzem 1 Gbit symmetrisch (Glasfaser).

Ist das deine Firma? Wenn Nein, Finger von.
Ich würde da strikt von Arbeit und Privat trennen, was solche Sachen angeht.
Willst du dann monatlich berechnen, was der Server bei dir kostet etc.?

Würde ich ganz klar von abraten.

 

[thetank7]

Ist das deine Firma? Wenn Nein, Finger von.
Ich würde da strikt von Arbeit und Privat trennen, was solche Sachen angeht.
Willst du dann monatlich berechnen, was der Server bei dir kostet etc.?

Würde ich ganz klar von abraten.

Ich werde die Firma bald übernehmen. Hatte ich nicht dazu geschrieben, weil ich dachte dass es für die Fragestellung irrelevant wäre.

Wie ich die privaten Stromkosten dann zumindest teilweise als Firmenausgabe deklariere, müsste ich noch prüfen, soll aber hierfür nicht entscheidend sein.

 

[cloudman]

Versuch zumindest mal grob die Kosten für Cloud vs on prem abzuschätzen.
Hardware Investition / geschätzte Laufzeit bis der Server ersetzt werden muß / Lizenzen / Backup / admin Aufwand vs Kosten Cloud
Am Ende des Tages ist es eine reine Kalkulationsgeschichte

 

[Piktogramm]

Im Sinne des Dogfooding[1], würde ich behaupten, dass ihr für eure Umgebung das wählen solltet, was auch produktiv zum Einsatz kommt. Wenn eure Softwareprodukte produktiv in der Cloud laufen, dann schiebt alles in die Cloud und wenn der Krempel in der Regel on Premise läuft, dann stellt euch Blech hin.
Das Ziel, den Aufwand für Ops gering zuhalten in allen Ehren. Gerade für eure Produkte solltet ihr jedoch Aufwand investieren, um Kunden diesen Aufwand abzunehmen.

[1]https://en.wikipedia.org/wiki/Eating_your_own_dog_food

 

[nosti]

Moin,

sehe ich wie @Piktogramm
Die Technik welche ihr “betreibt“ ist steinalt. Deswegen auch so laut und hitzköpfig. Eure Anforderungen sind nicht wirklich wild, bürotaugliche Silentserver gibt es mittlerweile ebenso.
Wenn on Premise notwendig sein sollte, kauft eine aktuelle Plattform und betreut bzw. Aktualisiert diese regelmäßig.

Grüße

 

[morcego]

Ihr solltet und werdet voraussichtlich etwas onPrem hinstellen. Ich würde mal vermuten ihr macht entweder direkt Desktop Apps die sich mit der DB verbinden oder per httpClient, also Web API.

Das was ihr nicht so wie heute von Azure bekommt ist euer SQL Server. Egal ob ihr den als Development oder Express Version betreibt, er kostet null Euro. Im Azure landet eure aktuelle Konfiguration eher so bei 1500-2000 pro Monat. SQL ist nämlich schweine teuer im Azure.
Selbst wenn ihr euch einen Standard lizensiert und dazu eure 3-5 CALs seit ihr immernoch billiger als ein Monat im Azure.
Sollten Kunden Azure SQL einsetzen, könnt ihr ja das Deployment im SSDT durchaus auch auf dieses Ziel setzen. Oder das macht die CI/CD irgendwie mit, damit hab ich noch keine Erfahrung.

Ob ihr die Windows VMs so betreiben dürft würd ich mal wenigstens mit Skepsis sehen.

Also mein Ansatz bei eurem Umfeld wäre schon onPrem.

• 1 oder sogar 2 Hosts kleine TowerServer mit Wartung, startet so bei etwa 800 (zumindest Fujitsu).
• Entweder die bisherige 2016er (Datacenter??) weiter verwenden oder halt gucken ob es was schon was neues wird
• AD DNS DHCP auf ein oder 2 VMs
• VPN auf Router oder VM
• SQL Development
• IIS für APIs
• Veeam für Backup (auf NAS)
• NAS für bisschen Datenhaltung was lokal liegen muss, Rest MS Wolke
• Azure DevOps (Migration der bisherigen git Repos)

 

[thetank7]

Ihr solltet und werdet voraussichtlich etwas onPrem hinstellen. Ich würde mal vermuten ihr macht entweder direkt Desktop Apps die sich mit der DB verbinden oder per httpClient, also Web API.

Das was ihr nicht so wie heute von Azure bekommt ist euer SQL Server.

Ob ihr die Windows VMs so betreiben dürft würd ich mal wenigstens mit Skepsis sehen.

Danke für Deinen Beitrag, du hast unser Tätigkeitsfeld ganz gut umrissen. Was du bzgl. des SQL Servers sagst ist auch mein Empfinden. Ich brauche die eher selten, aber dann auch richtig und Azure zieht uns da preislich schon etwas ab.
Was die Lizenzierung angeht, bin ich mir nicht ganz sicher. Durch die Silver Kompetenz haben wir 16 Cores vom Windows Server lizenziert. Bei der Standard Edition sind jeweils zwei VMs je Host inklusive. Also müssten beim Xeon X5550 4 Hosts + jeweils zwei VMs möglich sein bzw. wohl auch ein Host + 8 VMs.

 

[morcego]

Hehe, neee so rosa darfst du bei MS nicht rechnen. Mich wurde quasi gelehrt: "Wenn du bei MS 2 Optionen hättest, ist es idR die für den Kunden teurere."
Wenn du eine typische Standard Lizenz hast, dann sind da 2 VMs dabei. Unabhängig von den Kernen. Beim 2016 waren 8 oder 16 Kerne mit 2 CPUs (Sockeln) "lizensiert". Wenn du mehr VMs ODER mehr Kerne/CPUs hast, dann musst du weitere Standard Lizenzen kaufen. Du kannst da nicht einfach mit Sockeln x VM multiplizieren.

Schlussendlich rechnet sich das recht simpel

• kleiner Server mit sehr wenig VMs, zB nur 2, und diese ziehen innerhalb von 90 Tagen nicht um > Standard
• sehr viele VMs mit kleinem Server und freies Umzugsrecht > Datacenter.

Guck also nochmal sehr genau hin ob das bei euch eigentlich passt.
Und Windows VMs darf man ohne passende Lizensierung gar nicht virtualisieren, genauso wie Office.

Wenn ihr aber MSDN oder VS Abo habt, dann sind da doch auch Lizenzen drin. Eine Server Standard müsste da drin sein. Ihr köööönntet also vermutlich auf einem separaten physischen Host einen Standard mit eurem IIS und SQL aufsetzen der nur für Development zuständig ist. Ich bin zwar kein Pro in MS Lizensierung, aber für mein Verständnis ist das der Sinn dieser Dev Lizenzen.

Und euren produktiven Hauptserver setzt ihr dann nur mit dem notwendigen AD-Kernbetrieb auf. Damit kann der klein und billig lizensiert werden.

 

[nosti]

Das mit den Dev Lizenzen kommt aber ganz stark auf die Sichtweise an. Wir haben da auch schon interessante Diskussionen mit Auditoren gehabt. Das Testsystem soll physikalisch vom Prod-System getrennt sein. Es dürfen sich keinerlei produktive Daten oder ähnliches auf diesem System befinden, ob das einspielen ein alten Prod-DB für Testzwecke schon darunter fällt, konnte uns nicht sicher beantwortet werden.

Im Endeffekt ist das aber alles nur Schall und Rauch, wenn der Auditor der Meinung ist, dass es nicht korrekt lizensiert ist, nützt alles reden und betteln nix.

Grüße

 

[Rickmer]

Microsoft Lizenzierung hin oder her - aber realistisch gesehen, wird jemals ein Auditor bei einer 3-Mann-Bude auftauchen?

Veeam für Backup (auf NAS)

Ich würde hier dann auch empfehlen, den Storage per iSCSI einzubinden um ReFS für lange GFS Ketten nutzen zu können.

Veeam rät außerdem von SMB ab, siehe u.A. den untersten Punkt hier:
https://bp.veeam.com/vbr/3_Build_structures/B_Veeam_Components/B_backup_repositories/nas.html

• Tower Gehäuse, vlt schallgedämmt
• Ryzen 5 5600
• 32 GB ECC RAM
• günstiges B550 Board
• 4 x 2TB SSD im onboard RAID 1

32GB RAM wird schnell knapp, insbesondere falls Veeam dazu kommt. Hatte ich bei meinem Heimserver auch festgestellt. Ich würde direkt auf 64GB gehen.
Eure VMs würden sich sicherlich auch nicht über 1-2GB mehr RAM beschweren.

Schalldämmung sollte nicht vonnöten sein, insbesondere falls du direkt auf allflash Storage gehst. Vernünftiger CPU-Kühler, brauchbares Netzteil und das Teil bleibt unterhalb der Wahrnehmungsgrenze.

Bei den SSDs - meinst du Raid 1 oder Raid 10?
4 SSDs im Raid 1 ist mMn mehr Redundanz als man braucht, da gibt's erstmal andere Baustellen.

 

[nosti]

64GB RAM sin sicherlich nicht zu wenig. Gerade wen noch ein oder zwei DB Instanzen dazu kommen. Ich würde auch den Aufrüstpfad zu 128GB offen halten….wer weiß auf einmal sollt ihr Dienste Containerisieren und müsst zwei Kubernetes Cluster hoch ziehen. (Prod und Test)

Grundsätzlich bin ICH beim professionellen Einsatz kein Freund von selber bauen. Es gibt genügend Anbieter die euch auch Custom Server mit Garantie und Service verkaufen.
viele Entwickler wollen sich auch gar nicht um das Theme Serveradministration kümmern, immerhin werden die Jungs fürs programmieren bezahlt und nicht dafür IT Infrastruktur bereitzustellen. In einer kleinen Firma ist das oft anders, aber auch hier kann man Abhilfe schaffen.
Um ein Gefühl für die Kosten und den Aufwand zu bekommen, kann es helfen mit einem lokalen Systemhaus über das Thema zu sprechen. Ein unverbindliches Angebot bringt da sicherlich Klarheit. Gern auch mal eine Art „Servicevertrag“ mit anfragen…IT besteht immerhin nicht nur aus Hardware, auch bei Konfiguration und Updates von Betriebssystemen und (virtuellem) Netzwerken kann man viel falsch machen.

Grüße

 

[morcego]

Veeam rät außerdem von SMB ab, siehe u.A. den untersten Punkt hier:

Also ich kann dort an keiner Stelle erkennen, dass Veeam von SMB abrät. Da stehen lediglich Hinweise wenn man SMB nutzt.

 

[nubi80]

Also ich kann dort an keiner Stelle erkennen, dass Veeam von SMB abrät. Da stehen lediglich Hinweise wenn man SMB nutzt.

Es ist aber tatsächlich so, Veeam empfiehlt SMB nur als letzte Option zu benutzen. iSCSI ist deutlich performanter oder natürlich direct Storage.
Das Problem ist, dass beim SMB Zugriff die CPU der NAS die Berechnung des Veeam Backup Proxy machen muss. Bei iSCSI macht das der Host an dem die iSCSI LUN angebunden ist und die NAS muss nur noch Daten auf die Platten schreiben.