{"id":87282,"date":"2020-07-06T13:44:51","date_gmt":"2020-07-06T11:44:51","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/ot-startapa-do-tysyach-serverov-v-desyatke-czod-kak-my-gnalis-za-rostom-linux-infrastruktury"},"modified":"2021-02-01T11:41:48","modified_gmt":"2021-02-01T09:41:48","slug":"ot-startapa-do-tysyach-serverov-v-desyatke-czod-kak-my-gnalis-za-rostom-linux-infrastruktury","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/ot-startapa-do-tysyach-serverov-v-desyatke-czod-kak-my-gnalis-za-rostom-linux-infrastruktury","title":{"rendered":"Von einem \u201eStartup\u201c zu Tausenden von Servern in Dutzenden von Rechenzentren. Wie wir das Wachstum der Linux-Infrastruktur vorangetrieben haben.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Wenn Ihre IT-Infrastruktur zu schnell w\u00e4chst, stehen Sie irgendwann vor der Wahl \u2013 entweder die personellen Ressourcen linear zu erh\u00f6hen oder mit der Automatisierung zu beginnen. Bis zu einem gewissen Punkt lebten wir in der ersten Paradigme, bevor der lange Weg zur Infrastruktur als Code begann.<\/p>\n

\"Von
\n<\/a><\/noindex>
\nNat\u00fcrlich ist NSPK kein Startup, aber eine solche Atmosph\u00e4re herrschte in den ersten Jahren des Unternehmens, und es waren sehr interessante Jahre. Ich hei\u00dfe Dmitry Koryakov<\/a><\/noindex>, ich unterst\u00fctze seit \u00fcber 10 Jahren eine hochverf\u00fcgbare Linux-Infrastruktur. Ich trat dem NSPK-Team im Januar 2016 bei und hatte leider nicht die Gelegenheit, die Anf\u00e4nge des Unternehmens zu erleben, kam jedoch in einer Phase gro\u00dfer Ver\u00e4nderungen.<\/p>\n

Insgesamt l\u00e4sst sich sagen, dass unser Team zwei Produkte f\u00fcr das Unternehmen bereitstellt. Das erste ist die Infrastruktur. Die E-Mails m\u00fcssen zugestellt werden, DNS muss funktionieren, und die Domain Controller m\u00fcssen Ihnen den Zugang zu Servern erm\u00f6glichen, die nie ausfallen sollten. Die IT-Landschaft des Unternehmens ist riesig! Es handelt sich um business- und mission-critical Systeme, f\u00fcr die einige eine Verf\u00fcgbarkeitsanforderung von 99,999 % haben. Das zweite Produkt sind die Server selbst, sowohl physische als auch virtuelle. Bestehende Server m\u00fcssen \u00fcberwacht und neue regelm\u00e4\u00dfig an Kunden aus vielen Abteilungen geliefert werden. In diesem Artikel m\u00f6chte ich hervorheben, wie wir die Infrastruktur entwickelt haben, die f\u00fcr den Lebenszyklus verantwortlich ist. Server<\/a>.<\/p>\n

Der Beginn des Weges<\/b><\/p>\n

Zu Beginn sah unser Technologie-Stack folgenderma\u00dfen aus:
\nOS CentOS 7
\nDomain Controller FreeIPA
\nAutomatisierung \u2013 Ansible (+Tower), Cobbler<\/i><\/p>\n

All dies war auf drei Dom\u00e4nen verteilt, die in mehreren Rechenzentren untergebracht waren. In einem Rechenzentrum \u2013 B\u00fcrosysteme und Testumgebungen, in den anderen PROD.<\/p>\n

Die Erstellung von Servern sah zu einem bestimmten Zeitpunkt so aus:<\/p>\n

\"Von<\/p>\n

Im VM-Template CentOS minimal und das notwendige Minimum, wie z.B. eine korrekte \/etc\/resolv.conf, der Rest wird \u00fcber Ansible bereitgestellt.<\/p>\n

CMDB \u2013 Excel.<\/p>\n

Wenn der Server physisch ist, wurde anstelle der Kopie einer virtuellen Maschine das Betriebssystem mit Hilfe von Cobbler installiert \u2013 dabei werden die MAC-Adressen des Zielservers in die Cobbler-Konfiguration eingef\u00fcgt, der Server erh\u00e4lt per DHCP seine IP-Adresse und das Betriebssystem wird anschlie\u00dfend installiert.<\/p>\n

Anfangs haben wir sogar versucht, eine Art Konfigurationsmanagement in Cobbler zu betreiben. Doch im Laufe der Zeit brachte dies Probleme mit der Portabilit\u00e4t der Konfigurationen sowohl zu anderen Rechenzentren als auch zu dem Ansible-Code zur VM-Vorbereitung.<\/p>\n

Zu diesem Zeitpunkt sch\u00e4tzten viele von uns Ansible als eine praktische Erweiterung von Bash und nutzten bereitwillig Konstruktionen mit Shell und sed \u2013 kurz gesagt, Bashsible. Das f\u00fchrte letztendlich dazu, dass, wenn das Playbook aus irgendeinem Grund nicht auf dem Server funktionierte, es einfacher war, den Server zu l\u00f6schen, das Playbook anzupassen und alles erneut durchzuf\u00fchren. Es gab im Grunde kein Versionsmanagement f\u00fcr Skripte und auch keine Portabilit\u00e4t der Konfigurationen.<\/p>\n

Zum Beispiel wollten wir eine bestimmte Konfiguration auf allen Servern \u00e4ndern:<\/p>\n

    \n
  1. Wir \u00e4ndern die Konfiguration auf bestehenden Servern im logischen Segment\/Rechenzentrum. Manchmal nicht an einem Tag \u2013 die Verf\u00fcgbarkeit und das Gesetz der gro\u00dfen Zahlen erlauben es nicht, alle \u00c4nderungen gleichzeitig umzusetzen. Einige \u00c4nderungen sind potenziell destruktiv und erfordern einen Neustart \u2013 von Diensten bis hin zum Betriebssystem.<\/li>\n
  2. Korrekturen in Ansible<\/li>\n
  3. Korrekturen in Cobbler<\/li>\n
  4. Wiederholung N-mal f\u00fcr jedes logische Segment\/Rechenzentrum<\/li>\n<\/ol>\n

    Damit alle \u00c4nderungen reibungslos ablaufen, mussten zahlreiche Faktoren ber\u00fccksichtigt werden, und Ver\u00e4nderungen treten st\u00e4ndig auf.<\/p>\n