{"id":91090,"date":"2020-08-08T13:42:11","date_gmt":"2020-08-08T11:42:11","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/arhitektura-s3-3-goda-evolyuczii-mail-ru-cloud-storage"},"modified":"2020-08-08T13:42:11","modified_gmt":"2020-08-08T11:42:11","slug":"arhitektura-s3-3-goda-evolyuczii-mail-ru-cloud-storage","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/arhitektura-s3-3-goda-evolyuczii-mail-ru-cloud-storage","title":{"rendered":"S3-Architektur: 3 Jahre Evolution des Mail.ru Cloud Storage","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"S3-Architektur: 3 Jahre Evolution des Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/a53775776b3fc969cc15c9d13a64039d.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em><noindex><a rel=\"nofollow\" href=\"https:\/\/www.deviantart.com\/st-pete\/art\/Storage-Corridor-408874509\">Speicher-Korridor<\/a><\/noindex> von St-Pete<\/em><\/p>\n<p><\/p>\n<p>Hallo zusammen! Ich bin Mons Anderson, Plattformarchitekt <noindex><a rel=\"nofollow\" href=\"https:\/\/mcs.mail.ru\/\">Mail.ru Cloud L\u00f6sungen<\/a><\/noindex>, und ich erz\u00e4hle, wie wir unseren S3-Speicher aufgebaut haben, wie er funktioniert, welche L\u00f6sungen erfolgreich waren und welche wir \u00e4ndern w\u00fcrden, wenn wir ein \u00e4hnliches Projekt heute von Grund auf neu starten w\u00fcrden.<\/p>\n<p><\/p>\n<p>Dieser Artikel basiert auf einem Vortrag bei <noindex><a rel=\"nofollow\" href=\"https:\/\/corp.mail.ru\/ru\/press\/events\/databases-2\/\">@Databases Meetup<\/a><\/noindex> von Mail.ru Cloud Solutions &amp; Tarantool. In diesem Artikel werden wir besprechen:<\/p>\n<p><\/p>\n<ul>\n<li>wie das Mail.ru-Lager aufgebaut war, auf dessen Fundament wir das S3-Lager aufgebaut haben;<\/li>\n<li>was wir hinzugef\u00fcgt haben, um Mail.ru Cloud Storage zu entwickeln;<\/li>\n<li>wie das objektbasierte Speicher-Modell funktioniert und welche Schritte unternommen wurden, um es produktionsreif zu machen;<\/li>\n<li>\u00fcber die Weiterentwicklungen des Live-Systems: Failover und Skalierung;<\/li>\n<li>wie wir Sharding und Resharding umgesetzt haben;<\/li>\n<li>sowie die Arbeit mit SSL-Zertifikaten.<\/li>\n<\/ul>\n<p><\/p>\n<p>Wenn Sie nicht lesen m\u00f6chten, k\u00f6nnen Sie <noindex><a rel=\"nofollow\" href=\"https:\/\/youtu.be\/NEgm1nsv-qg\">sehen Sie sich an,<\/a><\/noindex>.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2 id=\"kak-bylo-ustroeno-hranilische-mailru-poverh-kotorogo-my-stroili-s3-hranilische\">Wie das Mail.ru-Lager aufgebaut war, auf dessen Fundament wir das S3-Lager aufgebaut haben,<\/h2>\n<p><\/p>\n<p>Die Entwicklung unseres S3 begann auf der Grundlage des Mail.ru Cloud-Lagers, daher ist es zun\u00e4chst wichtig zu erkl\u00e4ren, wie es strukturiert ist und was es kann.<\/p>\n<p><\/p>\n<p>Der Cloud-Speicher von Mail.ru besteht aus Servern mit Festplatten. Im Durchschnitt verf\u00fcgt ein moderner Storage-Server \u00fcber 36 Festplatten mit jeweils 12\u201314 Terabyte. Fr\u00fcher waren die Festplatten kleiner, aber im Laufe von drei Jahren hat sich die Speicherkapazit\u00e4t erheblich erh\u00f6ht, und heute sind es fast 500 Terabyte unstrukturierte Daten. <\/p>\n<p><\/p>\n<p>Festplatten von verschiedenen Servern des Speichers werden in sogenannten \u201ePairs\u201c zusammengefasst. Ein Paar ist eine Einheit zum Speichern von Dateien. Im Grunde genommen handelt es sich dabei um eine Festplatte, die in einen bestimmten Abschnitt an einem spezifischen Pfad eingebunden ist, wo Dateien gespeichert werden, die durch Hashes identifiziert werden. <\/p>\n<p><\/p>\n<p>Der Begriff Paar ist historisch bedingt und hat bis heute Bestand, obwohl es heutzutage nicht mehr zwingend nur zwei Festplatten in einem Paar gibt. Es k\u00f6nnen auch drei Festplatten sein, und es sind verschiedene hybride Speicherm\u00f6glichkeiten denkbar, zum Beispiel 3\/2. <\/p>\n<p>\n<img decoding=\"async\" alt=\"S3-Architektur: 3 Jahre Evolution des Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/544ab79846539262e2d4dff6ab95ffff.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><em>Paare (pair) sind Einheiten zum Speichern von Objekten.<\/em><\/p>\n<p><\/p>\n<p>Alle Paare werden in PairDB gespeichert \u2013 einer Anwendung auf Basis von Tarantool. Alle Datenbanken in unserem Speicher, beginnend mit den allerersten, basieren auf Tarantool; andere Datenbanken verwenden wir nicht.<\/p>\n<p><\/p>\n<p>PairDB speichert alle Paare, deren Zust\u00e4nde, verf\u00fcgbaren Speicherplatz, Ausfallm\u00f6glichkeiten und letzte Fehler. Es kann auch automatisch nach Paaren suchen, deren Zustand aktualisieren und \u00fcberpr\u00fcfen, ob sie funktionieren oder nicht. Das hei\u00dft, PairDB ist eine umfassende \u00dcbersicht \u00fcber den Zustand aller Festplatten in unserem System.<\/p>\n<p>\n<img decoding=\"async\" alt=\"S3-Architektur: 3 Jahre Evolution des Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/d50781b8b51ed5fe126bc84e19c934d1.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><em>Pair DB: Datenbank mit dem Zustand der Paare<\/em><\/p>\n<p><\/p>\n<p>In den Paaren werden Dateien gespeichert, und um zu wissen, welche Datei sich in welchem Paar befindet, ist eine weitere Datenbank \u2013 FileDB \u2013 erforderlich. Diese speichert die Zuordnung: welche Datei befindet sich in welchem Paar, sowie eine kleine Menge notwendiger Attribute.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"S3-Architektur: 3 Jahre Evolution des Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/b1a64737cf7f916bff446c10c1f01d4c.jpeg\" style=\"display:block;margin: 0 auto;\" \/><em>File DB: Ort, an dem die Datei gespeichert ist<\/em><\/p>\n<p>Ein weiteres wichtiges Glied ist der Service Nylon, ein Router f\u00fcr die Arbeit mit Datenbanken. Er ist der einzige Einstiegspunkt und erm\u00f6glicht die Nutzung einer einheitlichen Schnittstelle sowohl f\u00fcr PairDB als auch f\u00fcr FileDB. Dies ist ein stateless-Service, der die Anfragen ausbalanciert, versteht, zu welchem Shard von FileDB gegangen werden muss, und wei\u00df, welche Paare aktiv sind und welche nicht.<\/p>\n<p>\n<img decoding=\"async\" alt=\"S3-Architektur: 3 Jahre Evolution des Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/3e2225f229c8cfa462d620d2b5fb581e.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><em>Nylon: Router f\u00fcr die Arbeit mit Datenbanken<\/em><\/p>\n<p><\/p>\n<p>Um Inhalte im Speicher abzulegen, ben\u00f6tigen wir einen Service \u2013 Streamer. Dieser bietet zwei HTTP-Methoden: die PUT-Methode, um Inhalte in den Speicher hochzuladen, und die GET-Methode, um sie abzurufen. HTTP ist ein recht popul\u00e4res und praktisches Protokoll zur Daten\u00fcbertragung. <\/p>\n<p><\/p>\n<p>\u041a\u043e\u0433\u0434\u0430 \u043c\u044b \u043e\u0431\u0440\u0430\u0449\u0430\u0435\u043c\u0441\u044f \u043a Streamer&#8217;y, \u043e\u043d \u0447\u0435\u0440\u0435\u0437 Nylon \u043e\u0431\u0440\u0430\u0449\u0430\u0435\u0442\u0441\u044f \u043a PairDB, \u0432\u044b\u044f\u0441\u043d\u044f\u0435\u0442, \u043d\u0430 \u043a\u0430\u043a\u0443\u044e \u043f\u0430\u0440\u0443 \u043c\u043e\u0436\u043d\u043e \u0437\u0430\u043b\u0438\u0442\u044c \u0444\u0430\u0439\u043b, \u043f\u043e\u0441\u043b\u0435 \u0447\u0435\u0433\u043e \u043f\u0435\u0440\u0435\u0434\u0430\u0435\u0442 \u0434\u0430\u043d\u043d\u044b\u0435 \u043f\u043e WebDAV \u043d\u0430 \u044d\u0442\u0443 \u043f\u0430\u0440\u0443. <\/p>\n<p><\/p>\n<p>Im Grunde genommen ist jeder Storage-Server eine Kombination aus Nginx und Festplatten, die auf definierte Pfade gemountet sind. Wir k\u00f6nnen mit Streamer eine Datei in den Speicher hochladen, sie l\u00f6schen, umbenennen oder ihre Integrit\u00e4t pr\u00fcfen. Dies bietet eine praktische Schnittstelle f\u00fcr die Interaktion auf niedrigster Ebene mit dem Speicher. <\/p>\n<p>\n<img decoding=\"async\" alt=\"S3-Architektur: 3 Jahre Evolution des Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/3722a89ed44cace36e9cb1f8bee4bd1e.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><em>Streamer: der Zugriffspunkt zum Speicher<\/em><\/p>\n<p><\/p>\n<h2 id=\"chto-my-dobavili-chtoby-sdelat-s3-hranilische\">Was wir hinzugef\u00fcgt haben, um das S3-Speicherangebot zu verbessern<\/h2>\n<p><\/p>\n<p>Wir haben also die grundlegende Speicherinfrastruktur betrachtet, als wir uns darauf vorbereiteten, das S3-Speichersystem zu starten. Mit der PUT-Methode konnten wir beliebige Inhalte speichern und erhielten als Identifikator dieser Daten einen Hash. Mit diesem Identifizierer konnte man sp\u00e4ter die Originaldatei wieder abrufen. Doch das reicht nicht aus, um S3 vollst\u00e4ndig zu implementieren. Im S3-Protokoll gibt es neben der Speicherung von Objekten auch:<\/p>\n<p><\/p>\n<ul>\n<li>Speicherung von Metadaten \u2013 zus\u00e4tzlichen Eigenschaften von Objekten;<\/li>\n<li>Organisation des Zugriffs auf Objekte \u00fcber HTTP;<\/li>\n<li>Gruppierung von Objekten in Sammlungen \u2013 Buckets;<\/li>\n<li>HTTP-S3-Endpunkt. S3 organisiert Daten in bestimmten Strukturen \u2013 Buckets, von denen jeder einen Eingangspunkt f\u00fcr die Speicherung von Dateien bietet.<\/li>\n<\/ul>\n<p><\/p>\n<p>F\u00fcr die Umsetzung dieser Logik war ein separater Dienst erforderlich. Zudem m\u00f6chte man gleich die Architektur f\u00fcr das zuk\u00fcnftige Wachstum des Dienstes mit linearer Skalierbarkeit vorsehen.<\/p>\n<p><\/p>\n<h2 id=\"pervye-komponenty\">Die ersten Komponenten<\/h2>\n<p><\/p>\n<p>Ein Daemon, der die S3-API implementiert. Dies ist die standardisierte S3-API von Amazon, die XML f\u00fcr Metadaten unterst\u00fctzt und es erm\u00f6glicht, Inhalte direkt zu \u00fcbertragen. Wir mussten nichts Neues erfinden, alles ist dokumentiert und beschrieben.<\/p>\n<p><\/p>\n<p>Vor dem Dienst haben wir Nginx installiert. Diesen haben wir f\u00fcr die SSL-Terminierung, Lastenverteilung und einige Logik mit Lua (Metriken, Protokollierung und Tracing) verwendet.<\/p>\n<p><\/p>\n<p>F\u00fcr die Speicherung der S3-Metadaten haben wir ebenfalls Tarantool gew\u00e4hlt. In der ersten Version hat der S3-Daemon auf diese Datenbank zugegriffen, w\u00e4hrend der Inhalt in einem gro\u00dfen Speicher \u00fcber Streamer gespeichert wurde.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"S3-Architektur: 3 Jahre Evolution des Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/03dddec282b5bb41eb63748ccfb6c9a4.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>Nginx + S3-API + Metadaten<\/em><\/p>\n<p><\/p>\n<h2 id=\"obektnaya-model-hraneniya\">Objekt-basierte Speicherung<\/h2>\n<p><\/p>\n<p>Schauen wir uns an, wie S3 funktioniert. Der Benutzer kann einen Bucket erstellen \u2013 eine Sammlung von Objekten. Der Bucket wird durch den Hostnamen adressiert und ist ein Subdomain des Dienstes. Innerhalb des Buckets kann der Benutzer Objekte erstellen. Der Identifikator des Objekts ist die URL. Der Inhalt des Objekts ist ein Blob, ein Array von Bin\u00e4rdaten, das wir im Speicher aufbewahren werden. Das Objekt hat zudem Attribute: den Namen \u2013 die eben genannte URL, ACL (Zugriffssteuerungsliste), sowie andere zus\u00e4tzliche oder benutzerdefinierte Attribute \u2013 all dies wird in den Metadaten gespeichert. <\/p>\n<p><\/p>\n<p>Das normalisierte Schema dieser Daten k\u00f6nnte folgenderma\u00dfen aussehen: Es gibt Projekte, die Bucket besitzen, diese Buckets haben Objekte, und diese Objekte k\u00f6nnen zusammengesetzt sein. Da es eine M\u00f6glichkeit gibt, Objekte in Teilen zu laden, gibt es daf\u00fcr zwei Hilfstabellen: uploads und chunks. Zudem haben die Projekte Zugangsdaten und eine Abrechnung. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"S3-Architektur: 3 Jahre Evolution des Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/e2bede45ba4044f658b47a9840fd5224.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>Datenmodell<\/em><\/p>\n<p><\/p>\n<p>Da wir einen B2B-Service mit kostenpflichtigem Zugang erstellt haben, ben\u00f6tigte dieses Schema eine Abrechnung.<br \/>\nDen Abrechnungsdienst haben wir ebenfalls mit Tarantool implementiert. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"S3-Architektur: 3 Jahre Evolution des Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/d5b1a63e2273e933c95deecdb054bfe6.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<h2 id=\"dorabotki-s3-hranilischa-shagi-k-prodakshenu\">\u00dcberarbeitungen des S3-Speichers: Schritte zur Produktionsbereitschaft<\/h2>\n<p><\/p>\n<p>Wir haben bereits ein funktionierendes Modell entwickelt, das genutzt werden kann: Objekte und Metadaten wurden gespeichert, jedoch fehlten einige Punkte f\u00fcr den Produktionsstart.<\/p>\n<p><\/p>\n<p>Zun\u00e4chst das System der Ratenbegrenzungen. Wenn der Dienst ohne dieses gestartet wird, k\u00f6nnten wir bei hoher Last einen bestimmten Teil des Systems unvorhersehbar \u00fcberlasten. Die Ratenbegrenzung sollte so funktionieren: Jeder S3-Anfrage kommt an einem speziellen Host an, dieser Host ist der Identifikator des Buckets, und der Bucket geh\u00f6rt einem bestimmten Kunden. Wir m\u00fcssen eine Funktion f\u00fcr den Bucket definieren, die es erm\u00f6glicht, die Ratenbegrenzung zu berechnen. <\/p>\n<p><\/p>\n<p>Dar\u00fcber hinaus muss das Ratenlimit-System leistungsstark genug sein, um die Last zu bew\u00e4ltigen, die auf S3 einwirkt.<\/p>\n<p><\/p>\n<p>Hier haben wir erneut Tarantool verwendet. Die Ratenlimits bestehen aus einem Cluster von 21 Instanzen, die in Gruppen aufgeteilt, \u00fcber drei physische Knoten verteilt und zu einem gro\u00dfen topologischen Cluster zusammengeschlossen sind. Konfigurations\u00e4nderungen werden automatisch verbreitet: Ratenlimits, Standardwerte und Konfiguration werden festgelegt. Jeder Bucket wird strikt von einer einzigen Instanz bedient. Wenn ein bestimmter Bucket eine Anfrage erh\u00e4lt, wird die Instanz berechnet, die f\u00fcr diesen Bucket zust\u00e4ndig ist. Innerhalb dieses Knotens erfolgt die Berechnung des aktuellen Anfragevolumens anhand eines Algorithmus, der dem Token-Bucket \u00e4hnlich ist. Anschlie\u00dfend entscheidet das Ratenlimit-System auf Grundlage der aktuellen Last und der f\u00fcr den spezifischen Bucket festgelegten Eigenschaften, ob die Anfrage ausgef\u00fchrt werden kann oder nicht. Die \u00dcberpr\u00fcfung der Limits erfolgt zu Beginn der Ausf\u00fchrung der S3-Anfrage, um alle anderen Systemelemente vor \u00fcberm\u00e4\u00dfiger Last zu sch\u00fctzen. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"S3-Architektur: 3 Jahre Evolution des Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/1b91e5d1fe067c859ba9b36d58827579.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Auch unter Last ist es ziemlich schwierig, ohne Caching auszukommen. In S3 wird von mehrfachen Zugriffen auf dieselben Objekte ausgegangen, was es zu einem hei\u00dfen Speicherplatz macht. Normalerweise wird der Zugriff auf eine einzelne Datei \u00fcber die komplette Kette abgewickelt: Streamer, FileDB, PairDB, Storage. Bei mehrfachen Zugriffen auf eine Datei optimieren wir den Zugriff auf diesen Inhalt mithilfe eines lokalen Caches.<\/p>\n<p><\/p>\n<p>Das Caching ist mehrschichtig und wird durch nginx, lokale SSDs und RAM-Laufwerke realisiert. Wir haben hier Tarantool nicht verwendet, weil es bequemer ist, Objekte aus dem Dateisystem bereitzustellen; so k\u00f6nnen wir Caching-Tiering durchf\u00fchren. Zudem haben wir gro\u00dfe Objekte mit einer maximalen Gr\u00f6\u00dfe von 32 Gigabyte, w\u00e4hrend in Tarantool nur kleine Objekte gecacht werden k\u00f6nnen.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"S3-Architektur: 3 Jahre Evolution des Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/faa02bd52a1d70642589d775f22c5e75.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Dieses erste System, mit dem wir gestartet sind, hatte eine gew\u00e4hlte Kapazit\u00e4t, die f\u00fcr die Forschung und das Verst\u00e4ndnis des Produkts ausreichte, um festzustellen, dass es funktionieren wird. <\/p>\n<p><\/p>\n<h2 id=\"dorabotki-boevoy-sistemy-feylover-i-masshtabirovanie\">\u00dcberarbeitungen des Betriebssystems: Failover und Skalierung<\/h2>\n<p><\/p>\n<p>Das System war bereits im Einsatz, aber zu Beginn haben wir etwas \u00fcbersehen \u2013 wir h\u00e4tten Failover und Skalierung hinzuf\u00fcgen m\u00fcssen. <\/p>\n<p><\/p>\n<p>Unser S3-Daemon hat die Metadaten \u00fcber das Tarantool-Protokoll abgerufen. An die Stelle der urspr\u00fcnglichen Datenbank haben wir Tarantool gesetzt, das als Proxy-Router f\u00fcr die Anfragen nach den Metadaten fungierte. Aus Sicht der Anwendung, die die API implementiert, hat sich nichts ge\u00e4ndert \u2013 sie hat weiterhin \u00fcber das Tarantool-Protokoll auf die Datenbank zugegriffen, aber der Router konnte aktives Failover gew\u00e4hrleisten. Das hei\u00dft, wir konnten die Verf\u00fcgbarkeit des Knotens \u00fcberwachen, Pausen bei Umschaltungen und Ausf\u00e4llen einlegen usw. Dabei haben wir die Anwendung selbst nicht modifiziert. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"S3-Architektur: 3 Jahre Evolution des Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/978ff8a458f8d48b98672121cf6eca5d.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<h2 id=\"podrobnee-o-tom-kak-my-realizovali-shardirovanie\">Mehr erfahren, wie wir das Sharding umgesetzt haben<\/h2>\n<p><\/p>\n<p>Die n\u00e4chste Herausforderung, die angegangen werden musste, war das Sharding. Das System wuchs, die Anzahl der Objekte nahm zu und es war notwendig, M\u00f6glichkeiten f\u00fcr weiteres Wachstum zu schaffen.<\/p>\n<p><\/p>\n<p>Lassen Sie uns zum Datenschema zur\u00fcckkehren: Es gibt Projekte, es gibt Buckets, Kredite und Abrechnung. Dies sind Objekte, die mit gro\u00dfer Wahrscheinlichkeit in absehbarer Zeit weder in Volumen noch in Anfragen \u00fcber einen einzelnen Instanz hinauswachsen werden. Daher macht es keinen Sinn, sie zu sharden, und wir haben sie in eine separate Instanz ausgegliedert, die ungeshardet bleibt. Dies erm\u00f6glicht ein konsistenteres Management der Projekte und Buckets, da es einen einheitlichen, ungeshardeten Punkt gibt. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"S3-Architektur: 3 Jahre Evolution des Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/c5a1c1a875e756e3dceb5f885fbda2c8.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Im Schema gibt es auch Objekte, die linear wachsen \u2013 zuerst waren es Hunderttausende, jetzt wird ihre Anzahl in Milliarden gemessen. Solche Objekte und ihre Teile mussten in einen sharden Cluster verschoben werden. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"S3-Architektur: 3 Jahre Evolution des Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/00bb418cc61ad2e3e8797caf5d1ab202.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Wir haben das Schema aufgeteilt, aber die Objekte m\u00fcssen mit den Buckets arbeiten: Ein Objekt geh\u00f6rt immer zu einem bestimmten Bucket, und zudem arbeitet die ACL auf dem Bucket. Daher halten wir f\u00fcr jedes Shard mit Objekten eine Schattenkopie jedes Buckets. Dar\u00fcber hinaus m\u00fcssen wir bei der Modifikation von Objekten und der Ausf\u00fchrung von Anfragen das Volumen f\u00fcr die Abrechnung ber\u00fccksichtigen, weshalb in jedem Shard Abrechnungscounter vorhanden sind.<\/p>\n<p><\/p>\n<p>Au\u00dferdem haben wir einige weitere Tabellen und Komponenten hinzugef\u00fcgt:<\/p>\n<p><\/p>\n<ul>\n<li>Ein Container zum L\u00f6schen alter Projekte, die entfernt oder eingefroren werden;<\/li>\n<li>Eine Warteschlange f\u00fcr Hintergrundaufgaben, das hei\u00dft, der Hauptspeicher kann Hintergrundaufgaben ausf\u00fchren, die im Cluster erledigt werden m\u00fcssen;<\/li>\n<li>Unterst\u00fctzung des Lebenszyklus \u2014 ein Mechanismus, der es erm\u00f6glicht, mit Objekten zu arbeiten und deren Lebenszyklus zu verwalten.<\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"S3-Architektur: 3 Jahre Evolution des Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/933e98dc559eb8e6bac14003215a6836.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Da wir einen Teil der Daten auf Shards verteilt haben, ben\u00f6tigten wir einen Shard-Proxy. Man k\u00f6nnte den Router f\u00fcr diese Rolle wiederverwenden, aber ein separater Shard-Proxy, der nur f\u00fcr die Datenverteilung verantwortlich ist, erm\u00f6glicht es, die Daten vollst\u00e4ndig \u00fcber den Router abzurufen, ohne sich um das Sharding k\u00fcmmern zu m\u00fcssen.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"S3-Architektur: 3 Jahre Evolution des Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/4b181ed4629180e15558f25b1e4d5718.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ich werde separat erl\u00e4utern, warum wir keine fertige L\u00f6sung gew\u00e4hlt haben, sondern eine benutzerdefinierte Shard-Funktion entwickeln wollten. <\/p>\n<p><\/p>\n<p>Schauen wir uns an, wie sie aufgebaut ist. Wir haben 256 verf\u00fcgbare Shards. F\u00fcr jeden Bucket weisen wir einen Bereich mit einer konsistenten Funktion zu. Es ist einfach\u2014genauso wie man mit einer konsistenten Funktion die Zugeh\u00f6rigkeit zu einem Shard bestimmt, legt man den Start-Shard fest und weist einen Bereich zu:<\/p>\n<p><\/p>\n<p><code>f(bucket, shards) = subset<\/code><\/p>\n<p><\/p>\n<p>Das bedeutet, wenn wir einen Bucket betrachten, k\u00f6nnen wir sagen, dass er und seine Daten immer auf einer bestimmten Teilmenge aller Shards liegen werden. Dies reduziert den Einfluss eines Buckets auf andere und vereinfacht die Arbeit mit Map-Reduce-Anfragen, wenn wir zum Beispiel eine Auflistung der Bucket-Objekte erstellen m\u00fcssen. Dazu m\u00fcssen wir alle Shards abfragen, auf denen diese Objekte gespeichert sind. Wenn die Objekte auf allen Shards liegen w\u00fcrden, w\u00fcrde jede Auflistung das gesamte System beeintr\u00e4chtigen, w\u00e4hrend hier nur eine spezifische Teilmenge betroffen ist.<\/p>\n<p><\/p>\n<p>Weiterhin geh\u00f6rt jedes Objekt zu einem bestimmten Bucket, weshalb wir, wenn wir auf ein Objekt zugreifen, es anhand seines Namens in einem spezifischen Bucket anfordern. Das bedeutet, wir k\u00f6nnen die Funktion f\u00fcr das Objekt nicht aus dem gesamten verf\u00fcgbaren Bereich der Shards, sondern nur aus der Teilmenge seines Buckets definieren:<\/p>\n<p><\/p>\n<p><code>f(object, subset) = shard<\/code><\/p>\n<p><\/p>\n<p>Wir nehmen ein spezifisches Objekt und \u00fcbergeben dessen Teilmenge als Argumente an die Funktion, nicht alle Shards \u2013 und erhalten den spezifischen Shard. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"S3-Architektur: 3 Jahre Evolution des Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/10480ad2430c228c511ff3cdc5071596.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Also, Sharding ist implementiert, und es gibt einen Sharding-Proxy. Als n\u00e4chstes muss der Router zusammen mit der Metadatenbank auf den Sharding-Proxy zugreifen. Zum Beispiel, um Schattenkopien zu erstellen \u2013 wenn wir einen Bucket erstellen, muss der Hauptspeicher einen Vertreter dieses Buckets auf allen Shards anlegen, wo er vorhanden sein soll.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"S3-Architektur: 3 Jahre Evolution des Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/bb34d1f747903a3c2f08f582e4424787.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<h2 id=\"kak-my-realizovali-resharding\">Wie wir Resharding implementiert haben<\/h2>\n<p><\/p>\n<p>Das gr\u00f6\u00dfte Problem beim Sharding ist das Resharding. Es war uns wichtig, dies ohne Downtime zu realisieren, da das System bereits in Produktion war. Ich werde zeigen, wie wir das Problem anhand einer \u00e4hnlichen Aufgabe mit einer Live-Datenmigration von einem Projekt zu einem anderen gel\u00f6st haben.<\/p>\n<p><\/p>\n<p>Im Folgenden sehen Sie das Schema unseres Clusters, das nach der Implementierung von Sharding entstanden ist. Wir haben nginx, S3 API, einen Router, eine Primary-Datenbank mit Projekten, einen Sharding-Proxy und die Shards selbst.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"S3-Architektur: 3 Jahre Evolution des Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/0e6bd16c7fc47437b3b7d96b6d9809a4.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ich habe oben erw\u00e4hnt, dass es zu einem bestimmten Zeitpunkt im Projekt eine produktbezogene Aufgabe gab: 'Ein zus\u00e4tzliches Speicherger\u00e4t, Icebox, zu starten \u2013 \u00e4hnlich wie Hotbox, aber f\u00fcr kalte Daten'. Im Grunde handelt es sich um dasselbe Speicherger\u00e4t, jedoch unter einer anderen URL und ohne Caches.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"S3-Architektur: 3 Jahre Evolution des Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/9ce9085e1d03e9a99b6b8ccc0717c653.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Icebox wurde seltener verwendet als Hotbox, weshalb es lange ohne jegliches Sharding auskam. Am Ende haben wir beschlossen, es aufzugeben und Hotbox und Icebox zu einem einzigen Service zusammenzuf\u00fchren, indem wir einfach die Speicherkategorien getrennt haben. <\/p>\n<p><\/p>\n<p>Die Buckets in den Speichern \u00fcberschritten sich nicht, sie konnten leicht zusammengef\u00fchrt und verschoben werden. Da die Kunden jedoch sowohl den einen als auch den anderen Speicher nutzten, musste das Problem der Downtime gel\u00f6st werden. Wir konnten nicht einfach ausschalten und kopieren. Daher haben wir die Migration in mehreren Phasen durchgef\u00fchrt.<\/p>\n<p><\/p>\n<p>Zun\u00e4chst haben wir die Prim\u00e4rspeicher synchronisiert. Wir hatten Tarantool und konnten beim Erstellen eines Objekts Folgendes tun: <\/p>\n<p><\/p>\n<ul>\n<li>Eine Anfrage zur Erstellung eines Buckets, zum Beispiel in Hotbox, erreicht die Datenbank;<\/li>\n<li>Tarantool pr\u00fcft in einer anderen Datenbank (in diesem Fall in Icebox), dass es keinen solchen Bucket gibt;<\/li>\n<li>Wenn der Bucket existiert, teilt die Datenbank mit, dass er nicht erstellt werden kann, und er wurde als bestehend synchronisiert.<br \/>\n<img decoding=\"async\" alt=\"S3-Architektur: 3 Jahre Evolution des Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/6694c9804f09942416c1717b455b9fd3.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>Synchronisierung der Buckets<\/em><\/li>\n<\/ul>\n<p><\/p>\n<p>In dem Speicher, der alle Daten aufnehmen sollte, wurde f\u00fcr Projekte und Buckets ein Attribut eingef\u00fchrt, das angibt, wo dieses Objekt gespeichert ist. Es konnte lokal, also in Hotbox, oder in Icebox gespeichert werden \u2014 dann gibt es im neuen Speicher keine Daten davon, oder es k\u00f6nnte sich im Migrationsstatus befinden.<\/p>\n<p><\/p>\n<p>Wenn ein Projekt oder Bucket das Attribut Migrating hatte, wurde w\u00e4hrend der Migration die Anfrage zun\u00e4chst im neuen Speicher ausgef\u00fchrt, in dem die Daten sein sollten, und falls sie dort nicht vorhanden waren, wurden die Anfragen an den alternativen Speicher umgeleitet.<\/p>\n<p><\/p>\n<p>Anschlie\u00dfend haben wir den Traffic umgeschaltet. Da die API sowohl Icebox- als auch Hotbox-Anfragen bedienen konnte, konnten wir den Traffic ohne Ausfallzeit umschalten, indem wir einfach die Hosts verschoben und entsprechende Eintr\u00e4ge in Nginx hinzugef\u00fcgt haben. <\/p>\n<p><\/p>\n<p>Nachdem der Traffic umgeleitet war, konnte Nginx und die API von Icebox entfernt werden.<br \/>\nDann haben wir Icebox Nginx und S3 API entfernt \u2014 und alles lief wie gewohnt:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"S3-Architektur: 3 Jahre Evolution des Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/62d9f960fc1f11b875a8f8a5aa8e8152.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Anschlie\u00dfend haben wir einen Hintergrundprozess zur Migration gestartet, der innerhalb der Datenbank arbeitet \u2014 der nacheinander alle Projekte und deren Buckets durchl\u00e4uft, das Attribut Migrating setzt, die Daten \u00fcbertr\u00e4gt und nach Abschluss der \u00dcbertragung das Attribut Local setzt.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"S3-Architektur: 3 Jahre Evolution des Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/1a3129136f7ccacfdcff260f10cb0605.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Nach der Datenmigration ben\u00f6tigen wir den alten Speicher nicht mehr und entfernen die verbleibenden Teile des alten Systems sowie die Unterst\u00fctzung des Migrationsstatus aus dem Code.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"S3-Architektur: 3 Jahre Evolution des Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/13b6f11add40c21a3b9afc05dd0dfea9.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Der Re-Sharding vom alten Speicher auf den shardierten wurde nach denselben Prinzipien durchgef\u00fchrt:<\/p>\n<p><\/p>\n<ul>\n<li>Alle Buckets wurden als <code>Nicht-shardiert<\/code>markiert. Alle Anfragen an sie gingen an den urspr\u00fcnglichen, nicht-shardierten Speicher.<\/li>\n<li>Neue Buckets wurden direkt im Status <code>Shardiert<\/code>.<\/li>\n<li>erstellt. Einzelne Buckets wurden ausgew\u00e4hlt, der Status wurde auf <code>Migrating<\/code> gesetzt und die Daten wurden verschoben.<\/li>\n<\/ul>\n<p><\/p>\n<p>Anfragen wurden dabei nach folgendem Prinzip bearbeitet:<\/p>\n<p><\/p>\n<ul>\n<li>Zuerst im neuen lesen, dann im alten.<\/li>\n<li>Nur im neuen erstellen.<\/li>\n<li>Zweiphasen-Update: falls im neuen nicht vorhanden, werden die Daten vom alten in den neuen \u00fcberf\u00fchrt, danach wird aktualisiert.<\/li>\n<\/ul>\n<p><\/p>\n<h2 id=\"rabota-s-ssl-sertifikatami\">Arbeiten mit SSL-Zertifikaten<\/h2>\n<p><\/p>\n<blockquote><p>F\u00fcr das Frontend verwenden wir Nginx. In unserem Fall handelt es sich nicht um ein gew\u00f6hnliches Nginx, sondern um OpenResty, Nginx mit LuaJIT-Unterst\u00fctzung.<\/p><\/blockquote>\n<p>Ein weiterer Teil des Systems betrifft die Arbeit mit SSL-Zertifikaten. Im S3-Speicher k\u00f6nnen Sie eine eigene Domain f\u00fcr den Zugriff auf einen bestimmten Bucket einrichten, einfach durch <code>CNAME<\/code>. Aber ohne HTTPS geht es heutzutage nicht: eine eigene Domain setzt ein eigenes SSL-Zertifikat voraus. <\/p>\n<p><\/p>\n<p>Wie bereits erw\u00e4hnt, ist Nginx f\u00fcr das Load Balancing und die Termination von SSL verantwortlich. In unserem Fall handelt es sich nicht um ein gew\u00f6hnliches Nginx, sondern um OpenResty, Nginx mit Unterst\u00fctzung f\u00fcr LuaJIT.<\/p>\n<p><\/p>\n<p>Dies hat es uns erm\u00f6glicht, unseren Nginx relativ einfach beizubringen, beliebige Zertifikate bereitzustellen. Dabei war es notwendig, die Zertifikate dynamisch bereitzustellen (ohne sie in der Konfigurationsdatei festlegen zu m\u00fcssen). Wir haben das Modul <code>ssl_certificate_by_lua<\/code>, verwendet, das es erlaubt, das Zertifikat w\u00e4hrend des TLS-Handshakes direkt aus einer beliebigen Quelle zu lesen. Als Zertifikatsspeicher haben wir Tarantool gew\u00e4hlt: dies erm\u00f6glicht eine externe Verwaltung der Zertifikate und bietet extrem schnelle Zugriffszeiten.<\/p>\n<p><\/p>\n<p>\u0422\u0430\u043a\u0436\u0435 \u0431\u044b\u043b \u0440\u0435\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u044b\u0439 \u0434\u0435\u043c\u043e\u043d, \u0432 \u0437\u0430\u0434\u0430\u0447\u0443 \u043a\u043e\u0442\u043e\u0440\u043e\u0433\u043e \u0432\u0445\u043e\u0434\u0438\u0442 \u0440\u0435\u0433\u0443\u043b\u044f\u0440\u043d\u043e\u0435 \u043e\u0431\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u0435 \u0441\u0435\u0440\u0442\u0438\u0444\u0438\u043a\u0430\u0442\u043e\u0432, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0431\u044b\u043b\u0438 \u0432\u044b\u043f\u0438\u0441\u0430\u043d\u044b \u043f\u0440\u0438 \u043f\u043e\u043c\u043e\u0449\u0438 Let&#8217;s Encrypt.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"S3-Architektur: 3 Jahre Evolution des Mail.ru Cloud Storage\" src=\"\/wp-content\/uploads\/2020\/08\/8d61c1cb3084d9eb4eb8faa745e212db.jpeg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<h2 id=\"chto-by-ya-sohranil-a-chto-sdelal-po-drugomu-esli-razrabatyvat-hranilische-zanovo\">Was w\u00fcrde ich erhalten, und was w\u00fcrde ich anders machen, wenn ich den Speicher von Grund auf neu entwickeln w\u00fcrde?<\/h2>\n<p><\/p>\n<h3 id=\"chto-nuzhno-bylo-ispolzovat-s-samogo-nachala\">Was von Anfang an h\u00e4tte verwendet werden m\u00fcssen<\/h3>\n<p><\/p>\n<p><strong>Sharding sofort<\/strong>. Es gab einige Probleme mit dem Sharding. Es ist einfach zu machen, aber wenn man Projekte startet, die skalierbar sein m\u00fcssen, sollte man besser gleich einen shardierten Cluster w\u00e4hlen, selbst wenn es nur mit minimalen Knoten ist. Die Implementierung von Sharding zu Beginn ist nahezu kostenlos im Vergleich zur Einf\u00fchrung von Sharding in ein bestehendes System.<\/p>\n<p><\/p>\n<p><strong>Arbeiten mit Tarantool \u00fcber Load Balancer<\/strong>. Wir binden jetzt alle neuen Datenbanken sofort \u00fcber Load Balancer in den Betrieb ein. Das erm\u00f6glicht es, die Funktionalit\u00e4t zu erweitern und eine h\u00f6here Ausfallsicherheit zu erreichen. <\/p>\n<p><\/p>\n<p><strong>Auto-Failover<\/strong>. Ich w\u00fcrde alle Werkzeuge installieren, die f\u00fcr das Auto-Failover ben\u00f6tigt werden, da die ersten Misserfolge nach dem Start mit dessen Abwesenheit zusammenhingen. Nach den Erfahrungen mit S3 wurden alle nachfolgenden Produkte mit diesem Wissen implementiert.<\/p>\n<p><\/p>\n<p><strong>S3-Funktion \u201eVersionierung\u201c<\/strong>. Zun\u00e4chst schien mir diese Funktionalit\u00e4t nicht sehr gefragt zu sein. Diese M\u00f6glichkeit in die Architektur eines funktionierenden Systems zu integrieren, ist \u00e4u\u00dferst komplex.<\/p>\n<p><\/p>\n<p><strong>Getrennte Abrechnung<\/strong>. Die Art und Weise, wie wir das Billing in unser System integriert haben, war anfangs vielversprechend, hat sich jedoch sp\u00e4ter als st\u00f6rend erwiesen. Es w\u00e4re besser gewesen, es als v\u00f6llig separaten Service zu implementieren.<\/p>\n<p><\/p>\n<h3 id=\"chto-bylo-udachnym-resheniem\">Erfolgreiche Entscheidungen<\/h3>\n<p><\/p>\n<p><strong>Datenmodell<\/strong>. Die Erfahrung hat gezeigt, dass wir im Laufe der Entwicklung des Services sehr gut mit dem Datenmodell von Amazon \u00fcbereinstimmen, wodurch wir die dort vorhandenen Funktionen umsetzen k\u00f6nnen.<\/p>\n<p><\/p>\n<p><strong>Shard-Schema<\/strong>. Ich w\u00fcrde dieselben Bereichs-Shardings f\u00fcr Buckets unterst\u00fctzen, da dies eine gute Verteilung der Anfragen von verschiedenen Buckets \u00fcber ein gro\u00dfes Cluster erm\u00f6glicht.<\/p>\n<p><\/p>\n<p><strong>Einsatz von Tarantool<\/strong>. Tarantool hat bei der Weiterentwicklung und Modifikation des Services erheblich geholfen. Wir konnten problemlos mit Daten arbeiten, sie transformieren und das Speicher-Backend sharden, ohne in die Anwendungsschicht aufsteigen zu m\u00fcssen. <\/p>\n<p><\/p>\n<blockquote><p>Dieser Vortrag wurde erstmals gehalten auf <noindex><a rel=\"nofollow\" href=\"https:\/\/corp.mail.ru\/ru\/press\/events\/databases-2\/\">@Databases Meetup<\/a><\/noindex> by Mail.ru Cloud Solutions&amp;Tarantool. Sehen Sie sich das <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=jM4hL2u6JM0&amp;list=PLQzTaxmOHjntyNRPWhaWHqlHp8UN_wgQ3\">Video<\/a><\/noindex> anderer Vortr\u00e4ge an und abonnieren Sie die Veranstaltungshinweise auf Telegram. <noindex><a rel=\"nofollow\" href=\"https:\/\/t.me\/k8s_mail\">Rund um Kubernetes in der Mail.ru Group<\/a><\/noindex>.<\/p><\/blockquote>\n<p>Sie k\u00f6nnen auch meinen alten Vortrag \u00fcber S3 ansehen oder den Artikel meines Kollegen \u00fcber Blockspeicher lesen.<\/p>\n<p><\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=O0iIADHgBVc\">Reverse Engineering der Amazon S3 Architektur und wie das S3-Speicher von MCS vor 3 Jahren aussah<\/a><\/noindex>.<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/mailru\/blog\/472694\/\">Mehr als Ceph: Blockspeicher der Cloud MCS<\/a><\/noindex>.<\/li>\n<\/ul>\n<p>Quelle: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/mailru\/blog\/513356\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>Storage Corridor by St-Pete \u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u042f Mons Anderson, \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u043e\u0440 \u043f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u044b Mail.ru Cloud Solutions, \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443, \u043a\u0430\u043a \u043c\u044b \u043f\u043e\u0441\u0442\u0440\u043e\u0438\u043b\u0438 \u043d\u0430\u0448\u0435 S3-\u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0435, \u043a\u0430\u043a \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442, \u043a\u0430\u043a\u0438\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u044f \u043e\u043a\u0430\u0437\u0430\u043b\u0438\u0441\u044c \u0443\u0434\u0430\u0447\u043d\u044b\u043c\u0438, \u0430 \u043a\u0430\u043a\u0438\u0435 \u0441\u0442\u043e\u0438\u043b\u043e \u0438\u0437\u043c\u0435\u043d\u0438\u0442\u044c, \u0435\u0441\u043b\u0438 \u0431\u044b \u043c\u044b \u043d\u0430\u0447\u0430\u043b\u0438 \u0442\u0430\u043a\u043e\u0439 \u0436\u0435 \u043f\u0440\u043e\u0435\u043a\u0442 \u0441 \u043d\u0443\u043b\u044f \u0441\u0435\u0439\u0447\u0430\u0441. \u0421\u0442\u0430\u0442\u044c\u044f \u043f\u043e\u0434\u0433\u043e\u0442\u043e\u0432\u043b\u0435\u043d\u0430 \u043d\u0430 \u043e\u0441\u043d\u043e\u0432\u0435 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 \u043d\u0430 @Databases Meetup by Mail.ru Cloud Solutions &amp; Tarantool. [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":91091,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-91090","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 4.9.10 - aioseo.com -->\n\t<meta name=\"description\" content=\"Storage Corridor by St-Pete \u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u042f Mons Anderson, \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u043e\u0440 \u043f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u044b Mail.ru Cloud Solutions, \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443, \u043a\u0430\u043a \u043c\u044b \u043f\u043e\u0441\u0442\u0440\u043e\u0438\u043b\u0438 \u043d\u0430\u0448\u0435 S3-\u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0435, \u043a\u0430\u043a \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442, \u043a\u0430\u043a\u0438\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u044f \u043e\u043a\u0430\u0437\u0430\u043b\u0438\u0441\u044c \u0443\u0434\u0430\u0447\u043d\u044b\u043c\u0438, \u0430 \u043a\u0430\u043a\u0438\u0435 \u0441\u0442\u043e\u0438\u043b\u043e \u0438\u0437\u043c\u0435\u043d\u0438\u0442\u044c, \u0435\u0441\u043b\u0438 \u0431\u044b \u043c\u044b \u043d\u0430\u0447\u0430\u043b\u0438 \u0442\u0430\u043a\u043e\u0439 \u0436\u0435 \u043f\u0440\u043e\u0435\u043a\u0442 \u0441 \u043d\u0443\u043b\u044f \u0441\u0435\u0439\u0447\u0430\u0441. \u0421\u0442\u0430\u0442\u044c\u044f \u043f\u043e\u0434\u0433\u043e\u0442\u043e\u0432\u043b\u0435\u043d\u0430 \u043d\u0430 \u043e\u0441\u043d\u043e\u0432\u0435 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 \u043d\u0430 @Databases Meetup by Mail.ru Cloud Solutions &amp; Tarantool.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/arhitektura-s3-3-goda-evolyuczii-mail-ru-cloud-storage\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 4.9.10\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0410\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0430 S3: 3 \u0433\u043e\u0434\u0430 \u044d\u0432\u043e\u043b\u044e\u0446\u0438\u0438 Mail.ru Cloud Storage | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"Storage Corridor by St-Pete \u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u042f Mons Anderson, \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u043e\u0440 \u043f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u044b Mail.ru Cloud Solutions, \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443, \u043a\u0430\u043a \u043c\u044b \u043f\u043e\u0441\u0442\u0440\u043e\u0438\u043b\u0438 \u043d\u0430\u0448\u0435 S3-\u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0435, \u043a\u0430\u043a \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442, \u043a\u0430\u043a\u0438\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u044f \u043e\u043a\u0430\u0437\u0430\u043b\u0438\u0441\u044c \u0443\u0434\u0430\u0447\u043d\u044b\u043c\u0438, \u0430 \u043a\u0430\u043a\u0438\u0435 \u0441\u0442\u043e\u0438\u043b\u043e \u0438\u0437\u043c\u0435\u043d\u0438\u0442\u044c, \u0435\u0441\u043b\u0438 \u0431\u044b \u043c\u044b \u043d\u0430\u0447\u0430\u043b\u0438 \u0442\u0430\u043a\u043e\u0439 \u0436\u0435 \u043f\u0440\u043e\u0435\u043a\u0442 \u0441 \u043d\u0443\u043b\u044f \u0441\u0435\u0439\u0447\u0430\u0441. \u0421\u0442\u0430\u0442\u044c\u044f \u043f\u043e\u0434\u0433\u043e\u0442\u043e\u0432\u043b\u0435\u043d\u0430 \u043d\u0430 \u043e\u0441\u043d\u043e\u0432\u0435 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 \u043d\u0430 @Databases Meetup by Mail.ru Cloud Solutions &amp; Tarantool.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/arhitektura-s3-3-goda-evolyuczii-mail-ru-cloud-storage\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-08-08T11:42:11+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-08-08T11:42:11+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Architektur S3: 3 Jahre Evolution des Mail.ru Cloud Storage | ProHoster","description":"Storage Corridor von St-Pete  Hallo zusammen! Ich bin Mons Anderson, Architekt der Plattform Mail.ru Cloud Solutions. Ich werde Ihnen erz\u00e4hlen, wie wir unser S3-Speicher aufgebaut haben, wie es funktioniert, welche L\u00f6sungen erfolgreich waren und was wir anders machen w\u00fcrden, wenn wir dieses Projekt jetzt von Grund auf neu starten w\u00fcrden. Der Artikel basiert auf einem Vortrag beim @Databases Meetup von Mail.ru Cloud Solutions &amp; Tarantool.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/arhitektura-s3-3-goda-evolyuczii-mail-ru-cloud-storage","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0410\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0430 S3: 3 \u0433\u043e\u0434\u0430 \u044d\u0432\u043e\u043b\u044e\u0446\u0438\u0438 Mail.ru Cloud Storage | ProHoster","og:description":"Storage Corridor by St-Pete \u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u042f Mons Anderson, \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u043e\u0440 \u043f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u044b Mail.ru Cloud Solutions, \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443, \u043a\u0430\u043a \u043c\u044b \u043f\u043e\u0441\u0442\u0440\u043e\u0438\u043b\u0438 \u043d\u0430\u0448\u0435 S3-\u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0435, \u043a\u0430\u043a \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442, \u043a\u0430\u043a\u0438\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u044f \u043e\u043a\u0430\u0437\u0430\u043b\u0438\u0441\u044c \u0443\u0434\u0430\u0447\u043d\u044b\u043c\u0438, \u0430 \u043a\u0430\u043a\u0438\u0435 \u0441\u0442\u043e\u0438\u043b\u043e \u0438\u0437\u043c\u0435\u043d\u0438\u0442\u044c, \u0435\u0441\u043b\u0438 \u0431\u044b \u043c\u044b \u043d\u0430\u0447\u0430\u043b\u0438 \u0442\u0430\u043a\u043e\u0439 \u0436\u0435 \u043f\u0440\u043e\u0435\u043a\u0442 \u0441 \u043d\u0443\u043b\u044f \u0441\u0435\u0439\u0447\u0430\u0441. \u0421\u0442\u0430\u0442\u044c\u044f \u043f\u043e\u0434\u0433\u043e\u0442\u043e\u0432\u043b\u0435\u043d\u0430 \u043d\u0430 \u043e\u0441\u043d\u043e\u0432\u0435 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 \u043d\u0430 @Databases Meetup by Mail.ru Cloud Solutions &amp; Tarantool.","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/arhitektura-s3-3-goda-evolyuczii-mail-ru-cloud-storage","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-08-08T11:42:11+00:00","article:modified_time":"2020-08-08T11:42:11+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"91090","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 12:34:25","updated":"2022-10-02 13:27:50"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/91090","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=91090"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/91090\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/91091"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=91090"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=91090"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=91090"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}