Miniinterview mit Oleg Anastasyev: Fehlertoleranz in Apache Cassandra

Miniinterview mit Oleg Anastasyev: Fehlertoleranz in Apache Cassandra

Odnoklassniki ist der größte Benutzer von Apache Cassandra im RuNet und einer der größten weltweit. Wir haben 2010 begonnen, Cassandra zum Speichern von Fotobewertungen zu verwenden, und jetzt verwaltet Cassandra Petabytes an Daten auf Tausenden von Knoten, wir haben sogar unsere eigenen entwickelt NewSQL-Transaktionsdatenbank.
Am 12. September werden wir in unserem Büro in St. Petersburg eine Veranstaltung abhalten zweites Treffen, das Apache Cassandra gewidmet ist. Der Hauptredner der Veranstaltung wird der Chefingenieur von Odnoklassniki Oleg Anastasyev sein. Oleg ist ein Experte auf dem Gebiet verteilter und fehlertoleranter Systeme und arbeitet seit mehr als 10 Jahren und immer wieder mit Cassandra zusammen sprach über die Funktionen der Verwendung dieses Produkts auf Konferenzen.

Am Vorabend des Treffens sprachen wir mit Oleg über die Fehlertoleranz verteilter Systeme mit Cassandra, fragten, worüber er beim Treffen sprechen würde und warum es sich lohnt, an dieser Veranstaltung teilzunehmen.

Oleg begann seine Programmierkarriere bereits 1995. Er entwickelte Software für Banken, Telekommunikation und Transport. Seit 2007 arbeitet er als leitender Entwickler bei Odnoklassniki im Plattformteam. Zu seinen Aufgaben gehören die Entwicklung von Architekturen und Lösungen für Hochlastsysteme und große Data Warehouses sowie die Lösung von Problemen der Portalleistung und -zuverlässigkeit. Darüber hinaus schult er unternehmensintern Entwickler.

- Oleg, hallo! Im Mai stattgefunden erstes Treffen, Apache Cassandra gewidmet, sagen die Teilnehmer, dass die Diskussionen bis spät in die Nacht gedauert haben. Sagen Sie mir bitte, was sind Ihre Eindrücke vom ersten Treffen?

Entwickler mit unterschiedlichem Hintergrund aus verschiedenen Unternehmen kamen mit ihren eigenen Schmerzen, unerwarteten Problemlösungen und erstaunlichen Geschichten. Wir haben es geschafft, den Großteil des Treffens im Diskussionsformat durchzuführen, aber es gab so viele Diskussionen, dass wir nur ein Drittel der geplanten Themen ansprechen konnten. Wir haben viel Wert darauf gelegt, wie und was wir am Beispiel unserer realen Produktionsdienstleistungen überwachen.

Ich war interessiert und es hat mir sehr gut gefallen.

- Der Ankündigung nach zu urteilen, zweites Treffen Ich werde mich ausschließlich der Fehlertoleranz widmen. Warum haben Sie dieses Thema ausgewählt?

Cassandra ist ein typisches ausgelastetes verteiltes System mit einer Vielzahl von Funktionen, die über die direkte Bearbeitung von Benutzeranfragen hinausgehen: Klatsch, Fehlererkennung, Weitergabe von Schemaänderungen, Clustererweiterung/-reduzierung, Anti-Entropie, Sicherungen und Wiederherstellung usw. Wie in jedem verteilten System steigt die Wahrscheinlichkeit von Ausfällen mit zunehmender Hardwaremenge. Daher erfordert der Betrieb von Cassandra-Produktionsclustern ein tiefes Verständnis seiner Struktur, um das Verhalten bei Ausfällen und Bedieneraktionen vorherzusagen. Nachdem wir Cassandra viele Jahre lang verwendet haben, haben wir haben erhebliches Fachwissen angesammelt, die wir gerne teilen, und wir möchten auch besprechen, wie Kollegen in der Werkstatt typische Probleme lösen.

— Wenn es um Cassandra geht, was verstehen Sie unter Fehlertoleranz?

Zuallererst natürlich die Fähigkeit des Systems, typische Hardwareausfälle zu überstehen: Verlust von Maschinen, Festplatten oder Netzwerkkonnektivität mit Knoten/Rechenzentren. Aber das Thema selbst ist viel umfassender und umfasst insbesondere die Wiederherstellung nach Ausfällen, auch nach Ausfällen, auf die Menschen selten vorbereitet sind, beispielsweise Bedienerfehler.

— Können Sie ein Beispiel für den am stärksten ausgelasteten und größten Datencluster nennen?

Einer unserer größten Cluster ist der Gift-Cluster: mehr als 200 Knoten und Hunderte TB Daten. Es ist jedoch nicht das am stärksten belastete, da es von einem verteilten Cache abgedeckt wird. Unsere am stärksten ausgelasteten Cluster verarbeiten Zehntausende RPS zum Schreiben und Tausende RPS zum Lesen.

- Wow! Wie oft geht etwas kaputt?

Ja ständig! Insgesamt verfügen wir über mehr als 6 Server und jede Woche werden ein paar Server und mehrere Dutzend Festplatten ausgetauscht (ohne Berücksichtigung der parallelen Prozesse der Modernisierung und Erweiterung des Maschinenparks). Für jede Art von Fehler gibt es klare Anweisungen, was zu tun ist und in welcher Reihenfolge. Alles wird nach Möglichkeit automatisiert, sodass Fehler zur Routine gehören und in 99 % der Fälle vom Benutzer unbemerkt auftreten.

— Wie gehen Sie mit solchen Ablehnungen um?

Von Beginn des Betriebs von Cassandra und den ersten Vorfällen an haben wir an den Mechanismen für Backups und Wiederherstellung davon gearbeitet, Bereitstellungsverfahren entwickelt, die den Status von Cassandra-Clustern berücksichtigen und beispielsweise keinen Neustart von Knoten zulassen ob ein Datenverlust möglich ist. Darüber wollen wir beim Treffen sprechen.

— Wie Sie sagten, gibt es keine absolut zuverlässigen Systeme. Auf welche Arten von Ausfällen sind Sie vorbereitet und können Sie überleben?

Wenn wir über unsere Installationen von Cassandra-Clustern sprechen, werden Benutzer nichts bemerken, wenn wir mehrere Maschinen in einem DC oder einem ganzen DC verlieren (das ist passiert). Mit der Zunahme der DC-Anzahl denken wir darüber nach, mit der Sicherstellung der Funktionsfähigkeit bei Ausfall von zwei DCs zu beginnen.

— Was fehlt Cassandra Ihrer Meinung nach an Fehlertoleranz?

Cassandra erfordert, wie viele andere frühe NoSQL-Speicher, ein tiefes Verständnis seiner internen Struktur und der ablaufenden dynamischen Prozesse. Ich würde sagen, dass es an Einfachheit, Vorhersehbarkeit und Beobachtbarkeit mangelt. Aber es wird interessant sein, die Meinungen anderer Teilnehmer des Treffens zu hören!

Oleg, vielen Dank, dass du dir die Zeit genommen hast, die Fragen zu beantworten!

Wir erwarten alle, die sich mit Experten auf dem Gebiet des Betriebs von Apache Cassandra austauschen möchten, beim Treffen am 12. September in unserem Büro in St. Petersburg.

Kommen Sie, es wird interessant!

Melden Sie sich für die Veranstaltung an.

Source: habr.com

Kommentar hinzufügen