{"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 Servern in einem Dutzend 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 zur Unterst\u00fctzung linear erh\u00f6hen oder mit der Automatisierung beginnen. Bis zu einem bestimmten Punkt lebten wir im ersten Paradigma, und dann begann der lange Weg zu Infrastructure-as-Code.<\/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. Mein Name ist Dmitri Koryakov<\/a><\/noindex>, seit \u00fcber 10 Jahren unterst\u00fctze ich eine Linux-Infrastruktur mit hohen Verf\u00fcgbarkeitsanforderungen. Ich bin im Januar 2016 zum NSPK-Team gesto\u00dfen und habe leider nicht den Anfang des Unternehmens miterlebt, kam aber in einer Phase gro\u00dfer Ver\u00e4nderungen.<\/p>\n

Insgesamt kann man sagen, dass unser Team zwei Produkte f\u00fcr das Unternehmen liefert. Das erste ist die Infrastruktur. Die E-Mail muss funktionieren, DNS muss arbeiten und die Dom\u00e4nencontroller m\u00fcssen Ihnen den Zugang zu den Servern erm\u00f6glichen, die nicht ausfallen d\u00fcrfen. Die IT-Landschaft des Unternehmens ist riesig! Es sind business- und mission-critical Systeme, deren Verf\u00fcgbarkeitsanforderungen teilweise bei 99,999 liegen. Das zweite Produkt sind die Server selbst, sowohl physische als auch virtuelle. Die bestehenden m\u00fcssen \u00fcberwacht werden, w\u00e4hrend neue regelm\u00e4\u00dfig an Kunden aus verschiedenen Abteilungen geliefert werden. In diesem Artikel m\u00f6chte ich den Fokus darauf legen, wie wir die Infrastruktur entwickelt haben, die den Lebenszyklus verantwortet Server<\/a>.<\/p>\n

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

Zu Beginn unseres Weges sah unser Technologie-Stack so aus:
\nBetriebssystem CentOS 7
\nDom\u00e4nencontroller FreeIPA
\nAutomatisierung \u2013 Ansible (+Tower), Cobbler<\/i><\/p>\n

All dies war in 3 Dom\u00e4nen verteilt, die \u00fcber mehrere Rechenzentren verteilt waren. In einem Rechenzentrum \u2013 B\u00fcro- und Testsysteme, in den anderen PROD.<\/p>\n

Die Erstellung von Servern sah irgendwann so aus:<\/p>\n

\"Von<\/p>\n

Im VM-Vorlage CentOS minimal und das notwendigste wie ein korrektes \/etc\/resolv.conf, der Rest kommt \u00fcber Ansible.<\/p>\n

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

Wenn der Server physisch ist, wurde statt der Kopie einer virtuellen Maschine das Betriebssystem mit Cobbler installiert \u2013 die MAC-Adressen des Zielservers werden zur Cobbler-Konfiguration hinzugef\u00fcgt, der Server erh\u00e4lt \u00fcber DHCP eine IP-Adresse, und dann wird das Betriebssystem installiert.<\/p>\n

Zun\u00e4chst haben wir sogar versucht, eine Art Konfigurationsmanagement in Cobbler zu implementieren. Mit der Zeit brachte das jedoch Probleme bei der Portabilit\u00e4t der Konfigurationen sowohl zu anderen Rechenzentren als auch zum Ansible-Code zur Vorbereitung von VMs.<\/p>\n

Zu dieser Zeit betrachteten viele von uns Ansible als praktische Erweiterung von Bash und scheuten sich nicht, Konstruktionen mit Shell und sed zu verwenden. Im Grunde war es Bashsible. Dies f\u00fchrte letztendlich dazu, dass es einfacher war, einen Server zu l\u00f6schen, das Playbook zu korrigieren und es erneut auszuf\u00fchren, wenn das Playbook aus irgendeinem Grund nicht auf dem Server funktionierte. Es gab im Grunde kein Versionsmanagement f\u00fcr Skripte, auch nicht f\u00fcr die Portabilit\u00e4t von 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 Anforderungen an die Verf\u00fcgbarkeit und das Gesetz der gro\u00dfen Zahlen lassen nicht zu, dass alle \u00c4nderungen auf einmal angewendet werden. Einige \u00c4nderungen sind zudem potenziell destruktiv und erfordern einen Neustart von etwas, sei es von Diensten bis hin zum Betriebssystem selbst.<\/li>\n
  2. Korrektur in Ansible<\/li>\n
  3. Korrektur in Cobbler<\/li>\n
  4. Wiederholen Sie N-mal f\u00fcr jedes logische Segment\/Rechenzentrum<\/li>\n<\/ol>\n

    Um sicherzustellen, dass alle \u00c4nderungen reibungslos verlaufen, mussten viele Faktoren ber\u00fccksichtigt werden, und \u00c4nderungen sind st\u00e4ndig im Gange.<\/p>\n