Buch „Site Reliability Engineering. Zuverlässigkeit und Zuverlässigkeit wie bei Google »

Seit fast 20 Jahren bietet Google unvorstellbar komplexe und umfangreiche Systeme an, die auf Benutzeranfragen reagieren. Die Google-Suchmaschine findet die Antwort auf alle Fragen in Sekundenbruchteilen, Google Maps mit der höchsten Genauigkeit spiegeln die terrestrische Landschaft wider, und Google Mail ist im 365/24/7-Modus verfügbar und im Wesentlichen der erste öffentliche Cloud-Speicher. Sind diese Systeme fehlerfrei? Nein, sie versagen auch, brechen zusammen und werden veraltet, wie jedes Gerät. Wir bemerken es einfach nicht. Die Sache ist, dass Google seit mehr als zehn Jahren die einzigartige Site Reliability Engineering-Technologie entwickelt, die einen unterbrechungsfreien Betrieb und die fortschreitende Entwicklung von Softwaresystemen jeder Komplexität gewährleistet. Dieses Buch ist ein Erfahrungsschatz, den Google über viele Jahre gesammelt hat, die gemeinsame Arbeit vieler herausragender Spezialisten und eine unverzichtbare Ressource für jeden Ingenieur, der Produkte mit höchster Qualität und Effizienz entwickeln und warten möchte.

Googles SRE in Bezug auf SRE

Google-Rechenzentren (Rechenzentren) unterscheiden sich erheblich von herkömmlichen Rechenzentren und kleinen Server- "Farmen". Diese Unterschiede bringen sowohl zusätzliche Probleme als auch zusätzliche Möglichkeiten mit sich. In diesem Kapitel werden die Herausforderungen und Chancen für Google-Rechenzentren erläutert und die Terminologie vorgestellt, die im gesamten Buch verwendet wird.

Ausrüstung

Die meisten Computerressourcen von Google befinden sich in vom Unternehmen entworfenen Rechenzentren mit eigenem Stromversorgungssystem, Kühlsystem, internem Netzwerk und Computerausrüstung [Barroso et al., 2013]. Im Gegensatz zu typischen Rechenzentren, die Anbieter ihren Kunden zur Verfügung stellen, sind alle Google-Rechenzentren mit demselben ausgestattet1. Um Verwechslungen zwischen Serverhardware und Serversoftware zu vermeiden, verwenden wir in diesem Buch die folgende Terminologie:

• Maschine (Computer) - eine Geräteeinheit (oder möglicherweise eine virtuelle Maschine);
• Server - eine Softwareeinheit, die einen Dienst implementiert.

Jeder Server kann auf Computern gestartet werden, daher weisen wir bestimmten Serverprogrammen keine bestimmten Computer zu. Zum Beispiel haben wir keinen bestimmten Computer, auf dem der Mailserver ausgeführt wird. Stattdessen werden Ressourcen von unserem Borg-Cluster-Management-System zugewiesen.

Wir verstehen, dass eine solche Verwendung des Begriffs „Server“ nicht Standard ist. Es ist üblicher, zwei Konzepte gleichzeitig zu bezeichnen: ein Programm, das Netzwerkverbindungen bedient, und gleichzeitig einen Computer, auf dem solche Programme ausgeführt werden. Wenn wir jedoch über die Rechenleistung von Google sprechen, ist der Unterschied zwischen beiden erheblich. Sobald Sie sich an unsere Interpretation des Wortes "Server" gewöhnt haben, wird Ihnen klarer, warum es wichtig ist, diese spezielle Terminologie nicht nur direkt bei Google, sondern in diesem Buch zu verwenden.

In Abb. 2.1 demonstrierte die Konfiguration des Google-Rechenzentrums.

• Dutzende Autos stehen auf Gestellen.
• Gestelle stehen in Reihen.
• Eine oder mehrere Zeilen bilden einen Cluster.
• Normalerweise befinden sich im Gebäude eines Rechenzentrums (DPC) oder Rechenzentrums mehrere Cluster.
• Der Campus besteht aus mehreren nahe beieinander liegenden Rechenzentrumsgebäuden.

In jedem Rechenzentrum sollten alle Maschinen in der Lage sein, effektiv miteinander zu kommunizieren. Daher haben wir einen sehr schnellen virtuellen Switch (Switch) mit Zehntausenden von Ports erstellt. Dies war möglich, indem Hunderte von von Google entwickelten Switches zu einer „Fabrik“ verbunden wurden, die auf der Topologie des Clos-Netzwerks [Clos, 1953] namens Jupiter [Singh et al., 2015] basiert. Bei maximaler Konfiguration unterstützt Jupiter einen Durchsatz von 1,3 Pb / s zwischen Servern.

Rechenzentren sind über unser globales B4-Backbone-Netzwerk miteinander verbunden [Jain et al., 2013]. B4 verfügt über eine per Software konfigurierbare Netzwerkarchitektur und verwendet das OpenFlow Open Communication-Protokoll. B4 bietet eine breite Bandbreite für eine begrenzte Anzahl von Systemen und verwendet eine flexible Kanalbreitensteuerung, um den Durchschnittswert zu maximieren [Kumar et al., 2015].

Systemsoftware, die Geräte „organisiert“

Die Software, die die Verwaltung und Verwaltung unserer Geräte übernimmt, muss in der Lage sein, große Systeme zu handhaben. Hardwarefehler sind eines der Hauptprobleme, die mit Hilfe von Software gelöst werden. Angesichts der großen Anzahl von Hardwarekomponenten in einem Cluster treten diese häufig auf. In jedem Cluster fallen normalerweise Tausende von Computern pro Jahr aus und Tausende von Festplatten fallen aus. Wenn Sie diese Zahl mit der Anzahl der weltweit operierenden Cluster multiplizieren, ist das Ergebnis erstaunlich. Daher möchten wir Benutzer von solchen Problemen isolieren, und die an unseren Diensten beteiligten Teams möchten auch nicht durch Hardwareprobleme abgelenkt werden. Jeder Rechenzentrumscampus verfügt über Teams, die für die Unterstützung der Ausrüstung und Infrastruktur des Rechenzentrums verantwortlich sind.

Maschinenverwaltung

Borg (Abbildung 2.2) ist ein verteiltes Cluster-Management-System [Verma et al., 2015], ähnlich wie Apache Mesos. Borg verwaltet Jobs auf Clusterebene.
Borg ist für das Starten von Benutzerjobs verantwortlich. Diese Aufgaben können entweder ständig laufende Dienste oder Batch-Prozesse wie MapReduce sein [Dean und Ghemawat, 2004]. Sie können aus mehreren (manchmal Tausenden) identischen Aufgaben (Aufgaben) bestehen - sowohl aus Gründen der Zuverlässigkeit als auch weil ein Prozess in der Regel nicht den gesamten Clusterverkehr verarbeiten kann. Wenn Borg die Aufgabe startet, findet er die Maschinen, um seine Aufgaben auszuführen, und befiehlt ihnen, das Serverprogramm zu starten. Borg überwacht dann den Status dieser Aufgaben. Wenn die Aufgabe nicht ordnungsgemäß funktioniert, wird sie zerstört und möglicherweise auf einem anderen Computer neu gestartet.

Da Aufgaben frei auf Maschinen verteilt sind, können wir keine IP-Adressen und Portnummern verwenden, um darauf zuzugreifen. Dieses Problem wird durch eine zusätzliche Abstraktionsebene gelöst: Beim Starten einer Aufgabe weist Borg der Aufgabe mithilfe des Borg-Namensdienstes (BNS) einen Namen für die Aufgabe und eine Nummer (Index) zu. Anstatt die IP-Adresse und die Portnummer zu verwenden, verknüpfen andere Prozesse Borg-Tasks anhand ihres BNS-Namens, der dann den BNS in IP-Adresse und Portnummer konvertiert. Beispielsweise kann der BNS-Pfad eine Zeichenfolge wie / bns / <Cluster> / <Benutzer> / <Aufgabenname> / <Aufgabennummer> sein, die dann im Format <IP-Adresse>: <Port> übersetzt wird (es ist üblich, in Netzwerken "erlaubt" zu sagen) .

Borg ist auch für die Zuweisung von Ressourcen für Aufgaben verantwortlich. Jede Aufgabe sollte angeben, welche Ressourcen erforderlich sind, um sie abzuschließen (z. B. drei Prozessorkerne, 2 GB RAM). Mithilfe der Anforderungsliste für alle Aufgaben kann Borg Aufgaben unter Berücksichtigung von Fehlertoleranzaspekten optimal auf Maschinen verteilen (z. B. führt Borg nicht alle Aufgaben einer Aufgabe auf demselben Rack aus, da der Wechsel dieses Racks im Fehlerfall ein kritischer Punkt ist.) Aufgaben).

Wenn eine Aufgabe versucht, mehr Ressourcen als angefordert abzurufen, zerstört Borg sie und startet dann neu (da es normalerweise vorzuziehen ist, eine Aufgabe zu haben, die manchmal abstürzt und neu startet, als die überhaupt nicht neu gestartet wird).

Lagerung

Für einen schnelleren Zugriff auf Daten können Aufgaben die lokale Festplatte von Computern verwenden. Wir haben jedoch mehrere Optionen zum Organisieren des dauerhaften Speichers im Cluster (und sogar lokal gespeicherte Daten werden möglicherweise in den Clusterspeicher verschoben). Sie können mit Lustre und dem Hadoop Distributed File System (HDFS) verglichen werden - Clustered File Systems mit einer Open Source-Implementierung.

Durch die Speicherung können Benutzer einfach und zuverlässig auf Daten zugreifen, die dem Cluster zur Verfügung stehen. Wie in Abb. 2.3 hat das Repository mehrere Ebenen.


1. Die unterste Schicht heißt D (von der Festplatte, obwohl Stufe D sowohl herkömmliche Festplatten als auch Flash-Laufwerke verwendet). D ist ein Dateiserver, der auf praktisch allen Cluster-Computern ausgeführt wird. Benutzer, die auf ihre Daten zugreifen möchten, möchten sich jedoch nicht merken, auf welchem ​​Computer sie gespeichert sind. Daher wird hier die nächste Schicht verbunden.

2. Über Schicht D befindet sich die Colossus-Schicht, die im Cluster ein Dateisystem erstellt, das die übliche Semantik des Dateisystems sowie Replikation und Verschlüsselung bietet. Colossus ist der Nachfolger von GFS, dem Google File System (Ghemawat et al., 2003).

3. Als Nächstes werden mehrere datenbankähnliche Dienste über der Colossus-Ebene erstellt.

• Bigtable [Chang et al., 2006] ist ein nicht relationales (NoSQL) Datenbanksystem, das mit Petabyte-großen Datenbanken arbeiten kann. Bigtable ist eine dünn verteilte, fehlertolerante, mehrdimensionale, geordnete Datenbank, die nach Zeilen-, Spalten- und Zeitstempelschlüsseln indiziert ist. Jeder Datenbankwert ist ein beliebiges nicht interpretiertes Array von Bytes. Bigtable unterstützt auch die Replikation zwischen Rechenzentren.
• Spanner [Corbett et al., 2012] bietet eine SQL-ähnliche Oberfläche für Benutzer, die beim Zugriff von überall auf der Welt Datenintegrität und -konsistenz benötigen.
• Es stehen mehrere andere Datenbanksysteme zur Verfügung, z. B. Blobstore. Sie alle haben ihre eigenen Stärken und Schwächen (siehe Kapitel 26).

Netzwerk

Google Networking wird auf verschiedene Arten verwaltet. Wie bereits erwähnt, verwenden wir ein per Software konfigurierbares Netzwerk, das auf OpenFlow basiert. Anstelle von intelligenten Routern verwenden wir nicht so teure dumme Switches in Kombination mit einem zentralen (duplizierten) Controller, der die beste Route im Netzwerk vorberechnet. Auf diese Weise können Sie eine einfachere Schaltausrüstung verwenden und ihn von der zeitaufwändigen Routensuche befreien.

Die Netzwerkbandbreite sollte ordnungsgemäß zugewiesen werden. Da Borg die Rechenressourcen begrenzt, die eine Aufgabe verwenden kann, verwaltet Bandwidth Enforcer (BwE) die verfügbare Bandbreite, um den durchschnittlichen Durchsatz zu maximieren. Die Bandbreitenoptimierung hängt nicht nur mit den Kosten zusammen: Das zentralisierte Verkehrsmanagement löst eine Reihe von Problemen, die durch eine Kombination aus verteiltem Routing und herkömmlichem Verkehrsmanagement äußerst schwer zu lösen sind (Kumar, 2015).

Einige Dienste haben Jobs, die in mehreren Clustern in verschiedenen Teilen der Welt ausgeführt werden. Um die Verzögerungszeit global verteilter Systeme zu verringern, möchten wir Benutzer zum nächstgelegenen Rechenzentrum mit der dafür geeigneten Kapazität weiterleiten. Unser Global Software Load Balancer (GSLB) führt einen Lastausgleich auf drei Ebenen durch:

• Der geografische Lastausgleich für DNS-Abfragen (z. B. an www.google.com ) wird in Kapitel 19 beschrieben.
• Lastausgleich auf der Ebene der Benutzerdienste (z. B. YouTube oder Google Maps);
• Lastausgleich auf RPC-Ebene (Remote Procedure Call), beschrieben in Kapitel 20.

Servicebesitzer geben symbolische Namen für sie, eine Liste der Server-BNS-Adressen und die an jedem Standort verfügbare Leistung an (normalerweise wird sie in Abfragen pro Sekunde gemessen - Abfragen pro Sekunde, QPS). Anschließend leitet die GSLB den Verkehr an die angegebenen BNS-Adressen weiter.

Andere Systemsoftware

Die Rechenzentrums-Software enthält weitere wichtige Komponenten.

Sperrdienst

Der Chubby Lock Service [Burrows, 2006] bietet eine API, die dem Dateisystem zum Bereitstellen von Sperren ähnelt. Chubby behandelt Sperren in allen Rechenzentren. Es verwendet das Paxos-Protokoll, um asynchron auf den Konsens zuzugreifen (siehe Kapitel 23).

Chubby spielt auch eine wichtige Rolle bei der Auswahl eines Assistenten. Wenn für einen Dienst fünf Replikate einer Aufgabe bereitgestellt werden, um die Zuverlässigkeit zu erhöhen, aber zu einem bestimmten Zeitpunkt nur eines von ihnen die eigentliche Arbeit erledigt, wird Chubby verwendet, um dieses Replikat auszuwählen.
Chubby eignet sich hervorragend für Daten, die Speicherzuverlässigkeit erfordern. Aus diesem Grund verwendet BNS Chubby, um das Verhältnis von BNS-Pfaden zu IP-Adresse: Port-Paaren zu speichern.

Überwachung und Alarmierung

Wir möchten sicherstellen, dass alle Dienste ordnungsgemäß funktionieren. Aus diesem Grund starten wir viele Instanzen des Borgmon-Überwachungsprogramms (siehe Kapitel 10). Borgmon erhält regelmäßig Benchmark-Werte von überwachten Diensten. Diese Daten können sofort zur Benachrichtigung verwendet oder für die spätere Verarbeitung und Analyse gespeichert werden, beispielsweise zum Erstellen von Diagrammen. Eine solche Überwachung kann für folgende Zwecke verwendet werden:

• Einrichten von Warnungen für dringende Probleme;
• Verhaltensvergleich: Hat das Software-Update den Server beschleunigt?
• Einschätzung der Art der Änderungen des Ressourcenverbrauchs im Zeitverlauf, die für die Kapazitätsplanung erforderlich sind.

Unsere Software-Infrastruktur

Die Architektur unserer Software ist so konzipiert, dass die Hardwareressourcen des Systems am effizientesten genutzt werden können. Unser gesamter Code ist multithreaded, sodass eine Aufgabe problemlos mehrere Kerne verwenden kann. Zur Unterstützung von Dashboards, Überwachung und Debugging enthält jeder Server eine HTTP-Server-Implementierung als Schnittstelle, über die Diagnoseinformationen und Statistiken für eine bestimmte Aufgabe bereitgestellt werden.

Alle Google-Dienste „kommunizieren“ über die RPC-Infrastruktur (Remote Procedure Call) namens Stubby. Es gibt eine Open-Source-Version davon, sie heißt gRPC (siehe grpc.io ). Oft wird ein RPC-Aufruf auch für Routinen im lokalen Programm durchgeführt. Auf diese Weise können Sie das Programm an den Aufrufen eines anderen Servers ausrichten, um eine größere Modularität zu erzielen, oder wenn der ursprüngliche Servercode wächst. GSLB kann den RPC-Lastausgleich auf die gleiche Weise wie für externe Dienstschnittstellen durchführen.

Der Server empfängt RPC-Anforderungen vom Frontend und sendet den RPC an das Backend. Mit herkömmlichen Begriffen wird das Frontend als Client und das Backend als Server bezeichnet.
Die Datenübertragung zum und vom RPC erfolgt über das Serialisierungsprotokoll - die sogenannten Protokollpuffer oder kurz Protobufs. Dieses Protokoll ähnelt Apaches Thrift und bietet gegenüber XML mehrere Vorteile bei der Serialisierung strukturierter Daten: Es ist einfacher, drei- bis zehnmal kompakter, 20- bis 100-mal schneller und einzigartiger.

Unsere Entwicklungsumgebung

Die Geschwindigkeit der Produktentwicklung ist für Google sehr wichtig, daher haben wir eine spezielle Umgebung geschaffen, die unsere Infrastruktur optimal nutzt [Morgenthaler et al., 2012].

Mit Ausnahme einiger weniger Gruppen, deren Produkte Open Source sind und daher ihre eigenen separaten Repositorys verwenden (z. B. Android und Chrome), arbeiten die Softwareentwickler von Google in einem gemeinsamen Repository [Potvin, Levenberg, 2016]. Dieser Ansatz hat mehrere praktische Anwendungen, die für unseren Produktionsprozess wichtig sind.

• Wenn ein Ingenieur auf ein Problem in einer Komponente außerhalb seines Projekts stößt, kann er das Problem beheben, die vorgeschlagenen Änderungen („Änderungsliste“ - Änderungsliste, CL) zur Prüfung an den Eigentümer senden und dann die im Hauptzweig des Programms vorgenommenen Änderungen implementieren.
• Änderungen am Quellcode in einem eigenen Projekt eines Ingenieurs müssen berücksichtigt werden - Durchführung eines Audits (Überprüfung). Alle Software besteht diese Phase vor der Einführung.

Wenn die Software zusammengestellt wird, wird die Montageanforderung an spezialisierte Rechenzentrumserver gesendet. Selbst das Erstellen großer Projekte ist schnell, da Sie mehrere Server für die parallele Kompilierung verwenden können. Eine solche Infrastruktur wird auch für kontinuierliche Tests verwendet. Jedes Mal, wenn eine neue Änderungsliste (CL) angezeigt wird, werden Tests aller Software ausgeführt, die direkt oder indirekt von diesen Änderungen betroffen sein können. Wenn das Framework feststellt, dass die Änderungen den Betrieb anderer Teile des Systems gestört haben, benachrichtigt es den Eigentümer über diese Änderungen. Einige Projekte verwenden das Push-on-Green-System („Senden mit Erfolg“), nach dem die neue Version nach Bestehen der Tests automatisch an den kommerziellen Betrieb gesendet wird.

Shakespeare: Servicebeispiel

Betrachten Sie ein Beispiel für einen hypothetischen Dienst, der mit Google-Technologien interagiert, um zu demonstrieren, wie Google einen Dienst in einer industriellen Umgebung entwickelt. Angenommen, wir möchten einen Service anbieten, mit dem Sie bestimmen können, in welchen Werken von Shakespeare das von Ihnen erwähnte Wort vorkommt.

Wir können das System in zwei Teile teilen.

• Eine Stapelverarbeitungskomponente, die alle Shakespeare-Texte liest, einen Index erstellt und in Bigtable schreibt. Diese Aufgabe (genauer gesagt die Aufgabe) wird einmal oder möglicherweise gelegentlich ausgeführt (schließlich kann ein neuer Shakespeare-Text erscheinen!).
• Eine Front-End-Anwendung, die Endbenutzeranforderungen verarbeitet. Diese Aufgabe wird immer ausgeführt, da ein Benutzer aus einer beliebigen Zeitzone jederzeit Shakespeares Bücher durchsuchen möchte.

Die Stapelverarbeitungskomponente ist der MapReduce-Dienst, dessen Arbeit in drei Phasen unterteilt ist.

1. In der Mapping-Phase werden Shakespeares Texte gelesen und in separate Wörter unterteilt. Dieser Teil der Arbeit wird schneller erledigt, wenn mehrere Arbeitsprozesse (Aufgaben) parallel gestartet werden.

2. In der Shuffle-Phase werden die Einträge nach Wörtern sortiert.

3. In der Reduzierungsphase werden Tupel des Formulars (word, list_products) erstellt.

Jedes Tupel wird in Bigtable als Zeichenfolge geschrieben, der Schlüssel ist das Wort.

Lebenszyklus anfordern

In Abb. 2.4 zeigt, wie die Benutzeranforderung bedient wird. Zunächst klickt der Nutzer im Browser auf den Link shakespeare.google.com. Um die entsprechende IP-Adresse zu erhalten, übersetzt ("löst") das Gerät des Benutzers die Adresse mithilfe des DNS-Servers (1). Die DNS-Abfrage landet schließlich auf dem Google DNS-Server, der mit der GSLB interagiert. GSLB verfolgt die Verkehrslast aller Front-End-Server nach Region und wählt aus, welche IP-Adresse von welchem ​​Server an den Benutzer zurückgegeben werden soll.

Der Browser stellt unter der angegebenen Adresse eine Verbindung zum HTTP-Server her. Dieser Server (Google Frontend oder GFE genannt) ist ein "Reverse" -Proxy-Server, der sich am anderen Ende der TCP-Verbindung des Clients befindet (2). GFE sucht nach dem erforderlichen Dienst (z. B. kann es sich um einen Suchdienst, Karten oder - in unserem Fall den Shakespeare-Dienst) handeln. Durch wiederholten Zugriff auf die GSLB findet der Server einen verfügbaren Shakespeare-Front-End-Server und greift über einen Remote Procedure Call (RPC) darauf zu, wobei eine vom Benutzer empfangene HTTP-Anforderung gesendet wird (3).

Der Shakespeare-Server analysiert die HTTP-Anforderung und erstellt einen „Protokollpuffer“ (protobuf), der die zu findenden Wörter enthält. Jetzt sollte der Shakespeare-Front-End-Server den Shakespeare-Back-End-Server kontaktieren: Der erste kontaktiert die GSLB, um die BNS-Adresse einer geeigneten und entladenen Instanz der zweiten zu erhalten (4). Als nächstes kontaktiert der Shakespeare-Backend-Server den Bigtable-Server, um die angeforderten Daten zu empfangen (5).

Das Ergebnis wird in den Antwortprotobuf geschrieben und an den Shakespeare-Backend-Server zurückgegeben. Das Backend übergibt protobuf mit dem Ergebnis des Dienstes an den Shakespeare-Front-End-Server, der ein HTML-Dokument erstellt und es als Antwort an den Benutzer zurückgibt.


Diese ganze Kette von Ereignissen läuft im Handumdrehen ab - in nur wenigen hundert Millisekunden! Da viele Komponenten beteiligt sind, gibt es viele Stellen, an denen ein potenzieller Fehler auftreten kann. Insbesondere ein Fehler in der GSLB kann alle Arbeiten desorganisieren und zum Zusammenbruch führen. Google, , ( ), , . , www.google.com , .

, - 100 (QPS). , 3470 QPS, 35 . , 37 , N + 2.

• , 36 .
• , - 35 — , .

: 1430 QPS , 290 — , 1400 — 350 — . - , : , , . N + 2 , 17 , 16 — — . , , ( ), — N + 2 N + 1. : GSLB - , 20 % , . 2–3 .

- Bigtable, . - Bigtable, , , Bigtable . , Bigtable , . Bigtable , , .

, . , , .

»Weitere Informationen zum Buch finden Sie auf der Website des Herausgebers
» Inhalt
» Auszug

20% — Site Reliability Engineering