Wir stellen das beste Krediterkennungssystem in Russland und den Nachbarländern her. In einer idealen Welt würden wir uns nur mit dem Design und der Entwicklung des Systems befassen. Leider funktioniert Anti-Plagiat nicht im luftleeren Raum, und damit unsere Benutzer unsere Entwicklungen bequem und bequem nutzen können, müssen wir auch die Umgebung für unseren Service entwickeln. Unsere Software funktioniert noch nicht ohne Bügeleisen. Benutzer müssen technischen Support leisten. Sie müssen Zahlungen von Benutzern erhalten, ohne gegen das Gesetz zu verstoßen. Kurz gesagt, die Routine ist genug.

Dieser Artikel ist der erste einer Reihe von Produktionsdramen darüber, wie wir unseren Service durch Outsourcing verbessert haben. Wir teilen echte Probleme und Schlussfolgerungen.

Wolken, blonde Pferde ...

^{(Von irgendwo im Internet habe ich es hier zum ersten Mal gesehen.)}

Die Belastung unseres Systems ist sehr ungleichmäßig: Erstens ändert sich die Belastung tagsüber fünfmal. Zweitens gibt es eine ausgeprägte Saisonalität. Das tägliche Maximum an Schecks nach dem Ende der Sommersitzung wird um das 10-fache reduziert! Die Wintersitzung ist nicht so hell, aber auch kein Geschenk. Außerdem ist jede nachfolgende Sommersitzung schwerer (in Bezug auf die Anzahl der Überprüfungen) und schwieriger (neue Suchtechnologien und -funktionen) als die vorherige. Daher möchte ich einerseits eine gute Versorgung mit Ressourcen haben, andererseits zahle ich bei einem Rückgang der Aktivität nicht zu viel. In einer Sitzung können Sie mehr Server bereitstellen und im Sommer den Ressourcenverbrauch reduzieren. Dies ist natürlich nur bei Cloud-Anbietern der Fall. In diesem Artikel werde ich über verschiedene Aspekte der Interaktion mit mehreren Cloud-Anbietern (AWS, IT Grad, MCS, YC) sprechen. Wenn es jemandem scheint, dass dies ein Schrei der Seele ist, wird er sich nicht sehr irren. Also lass uns gehen!

Aws

Wir haben im Februar 2013 mit der Nutzung von Cloud-Ressourcen begonnen, als wir unseren ersten Server in AWS gemietet haben. Tatsächlich ist Amazon das erste und am längsten laufende Anti-Plagiat-Erlebnis mit den Wolken. Dann haben wir mit einer Maschine angefangen, und jetzt ist unser Budget in AWS um eine Größenordnung höher als das Budget für alle russischen Clouds. Die erste Liebe wird, wie Sie wissen, nie vergessen. Alle Probleme und Möglichkeiten mit anderen Clouds in diesem Artikel habe ich aufgrund der Erfahrung mit AWS berücksichtigt.

Es stimmt, es gab auch eine Fliege in der Salbe in Bezug auf Amazon. Im Folgenden sind die Funktionen oder Unannehmlichkeiten aufgeführt, die wir mit Amazon haben:

1. Sie können nicht über einen Browser auf die Konsole einer virtuellen Maschine zugreifen. Und manchmal ist es genau hier wirklich nötig! Einmal haben wir versehentlich die Netzwerkschnittstelle gelöscht und der Zugriff auf einen der Computer ging verloren. Es war ein Glück, dass jemand bereits auf ein solches Problem gestoßen war. In einer halben Stunde haben wir die Lösung gefunden und erfolgreich angewendet. Über die Konsole kann ein solcher Vorgang in einer Minute ausgeführt werden.
2. Die Kosten sind in Dollar angegeben und wir verdienen in Rubel. Dementsprechend hängt die Rentabilität vom Dollar ab.
3. In Russland gibt es kein Rechenzentrum. Als wir anfingen, war Irland am nächsten. Dies bedeutet einen großen Ping und einige Einschränkungen bei der Datenspeicherung, die sich aus den Anforderungen des russischen Rechts ergeben.
4. Roskomnadzor blockiert regelmäßig AWS-Adressen. Derzeit gibt es in AWS unterschiedliche Serververfügbarkeiten von verschiedenen Standorten. Aus unbekannten Gründen kann die Verbindung zur Maschine unterbrochen werden. Normalerweise hilft das Ändern der IP-Adresse, des VPN und des Proxys.
5. Amazon ist deutlich teurer als russische Clouds. Richtig, Sie können die Kosten durch ein flexibles Sicherungsprogramm und die Verwendung von Spot-Instanzen senken. Und wir nutzen beide aktiv. Leider haben wir solche Funktionen in inländischen Clouds noch nicht gesehen (Update: YC hat im Newsletter vom 18. Februar "unterbrochene VMs" angekündigt, wir warten auf Details).
6. Das Problem mit unzureichend informativen Nachrichten. Während des Übergangs von der 3. Maschinengeneration zur 4. oder 5. Generation änderte die virtuelle Hardware erheblich, insbesondere die Methode zum Anschließen von Laufwerken, und die Maschinen wurden nach dem Typwechsel einfach nicht gestartet. Die Instanzverwaltungsschnittstelle gab eine kurze Meldung zurück: unzureichende Kapazität. Es gab genügend Grenzwerte, um die erforderlichen Maschinentypen mit einem gewissen Spielraum zu erstellen, und etwa sechs Monate lang haben wir den kostenlosen technischen Support auf Kosten der Änderung der Grenzwerte erfolglos gefoltert. Es hat nicht geholfen. Infolgedessen haben sie die Lösung selbst gegoogelt - eine banale Nachbildung der Maschinen hilft.
7. Ein paar Mal haben wir SSDs in Lücken gelöscht: Festplatten verschwanden einfach zusammen mit allen Daten aus dem System. Vorausgesetzt, dies waren kurzlebige Scheiben , d.h. Daten gehen verloren, wenn die Maschine stoppt. Wir haben nichts Unersetzliches darauf gespeichert.

Grundsätzlich war es möglich, mit diesen Mängeln zu leben. Genau in dem Moment, als Amazon endlich den russischen Markt bemerkte, wurde unser Konto für die Zahlung mit einer Karte nicht sehr praktisch. Glücklicherweise korrigierte Amazon die Situation schnell und stellte uns einen Account Manager zur Verfügung, der uns half, von der Zahlung über eine Karte zu einem direkten Vertrag überzugehen, eine Rechnung zu bezahlen und verschiedene Arten von Vereinbarungen zu erstellen. Im Allgemeinen kommt er regelmäßig nach Russland, und wenn er zu uns kommt, spricht er über Möglichkeiten zur Optimierung der Infrastruktur und des Zahlungsverkehrs. Manchmal bringt er einen Solution Architect mit, mit dem er die aktuelle Architektur unserer Lösung besprechen, über „Wunschliste“ und Probleme sprechen und mehrere Lösungen erhalten kann, nicht nur über AWS-Services. Amazon-Mitarbeiter erklären, dass ihr Ziel nicht darin besteht, mehr Dienste bereitzustellen, sondern sicherzustellen, dass die gekauften Dienste dem Unternehmen zugute kommen. Es scheint, dass dies wirklich wahr ist. Die Anzahl der Dienste, die Geschwindigkeit ihrer Entwicklung und die Tiefe der gegenseitigen Integration sind beeindruckend. AWS bietet alles, um sowohl den Entwicklungsprozess als auch den Betrieb hoch belasteter Systeme jeder Größenordnung zu organisieren. Bisher ist nur ein globales Problem teuer!

IT Grad 2016

2015 haben wir beschlossen, dass es Zeit für uns ist, unser eigenes Eisen komplett aufzugeben. Ich wollte die Probleme auf die Zuverlässigkeit der Geräte speziell auf andere legen und mich mehr auf die Verbesserung der Prozesse unserer eigenen Entwicklung konzentrieren. Nach unseren Prognosen hätten wir 2016 genug von der Ausrüstung gehabt, die wir gerade hatten, und wir hätten gerne eine Reserve für jedes Brandereignis. Wir haben uns gründlich mit der Wahl des Anbieters befasst: Wir haben einen Auslastungstest und einen Fragebogen mit wichtigen Fragen für uns vorbereitet und akribisch aus fünf Anbietern ausgewählt: ActiveCloud, Cloud4Y, CloudOne, IT Grad, Softline.

Aus diesem Grund haben wir uns für IT Grad Clouds entschieden. Ihre Vorteile:

1. Aktive Lebensposition, Antworten auf unsere Fragen wurden schnell gegeben, es war einfach zu kommunizieren.
2. Das Vorhandensein schneller SSD-Laufwerke, bis zu 30 IOPS pro GB. Die Anzahl der zufälligen Lesevorgänge ist für uns ein sehr wichtiger Indikator, da wir mit hohen Werten unsere Scanmodule in der Cloud platzieren können.
3. VCloud-Plattform mit der Fähigkeit zur Steuerung von Maschinen und dem Vorhandensein einer Konsole für jede Maschine.
4. Die Möglichkeit, die Ressourcen einer virtuellen Maschine ohne Neustart zu erhöhen.
5. Flexible Abrechnung - Die Zahlung erfolgt für Ressourcen, die am Tag in der Mitte des Berichtszeitraums (am 14.-15. Tag eines jeden Monats) verwendet wurden. Darüber hinaus gibt es eine "Pay-As-You-Go" -Option, die jedoch teurer ist und die Berechnung des Ressourcenverbrauchs durch die durchschnittliche CPU- und RAM-Auslastung alle 2 Stunden erfolgt.

2016 sind wir zu IT Grad gewechselt. Folgendes ist in den unvollständigen drei Jahren unseres gemeinsamen Lebens passiert:

1. Einmal hatten wir ein Problem. Genau um 21:00 Uhr begann ein merkwürdiger Leistungsabfall. Die Anzahl der Überprüfungen, die das System durchführen konnte, sank von 150 auf 20 bis 30 pro Minute, während nach einigen Stunden alles mit einer Geschwindigkeit von 600 Überprüfungen pro Minute wiederhergestellt und aufgelöst wurde. Wir haben eine Woche zu Hause gesucht, Benutzer überprüft, Bots und DDoS gefangen, aber nichts gefunden. Wir haben uns an die Unterstützung von IT-Grad gewandt und festgestellt, dass "oh, und wir machen hier Backups". Infolgedessen haben sie uns mit einer Quelle von Problemen auf verschiedenen Festplattensystemen zerschlagen und die Arbeit eingerichtet.
2. Normalerweise (Funktionen bei der Verwendung des Produkts) überschreitet unser Datenverkehr während einer Sitzung 100 Megabit pro Sekunde. Dieser Wert wird übrigens in vielen Cloud-Anbietern häufig standardmäßig für den nicht reservierten Kanal festgelegt. Als wir diese Grenze zum ersten Mal überschritten haben, traten einige Probleme auf: Der integrierte Edge konnte das VPN zwischen dem Einstiegspunkt auf unseren Geräten und der virtuellen Maschine des Webservers in der Cloud nicht bewältigen. Wie erwartet wandten sie sich an den Support, wo uns angeboten wurde, die Ressourcen auf Edge zu erhöhen. Ok, keine Frage, wir haben seine Konfiguration von klein auf groß ersetzt und den Kanal mit einem Rand auf die Größe unseres Spitzenverkehrs erweitert. Es hat nicht geholfen. Im Allgemeinen konnten wir keine optimale Lösung finden. Ich musste das Verkehrsaufkommen reduzieren, indem ich einen Teil der Produktion auf andere Standorte verlagerte.
3. Die VPN-Verbindung zur IT Grad-Site wird manchmal für 1-2 Minuten unterbrochen. Auf die Frage, warum dies geschieht, können weder wir noch der technische Support die Antwort finden. Bisher muss ich mit diesem Problem leben.
4. Der Mechanismus zum Ändern der Ressourcengröße funktioniert sowohl im laufenden Betrieb als auch im ausgeschalteten Zustand schlecht. Es scheint mir jedoch, dass dies eher ein Problem mit dem Plattformanbieter (VMware) ist. Wir haben jedoch bereits festgestellt, dass der Gastcomputer (Windows Server 2012 R2) neu gestartet werden musste, um alle Erweiterungen zuverlässig anwenden zu können. Nach der Größenänderung wurde der Computer selbst nicht mehrmals gestartet. Der Support hat dieses Problem einmal von 2 bis 4 Uhr morgens während der Sitzung behoben - genau in unserer Saison. Es war sogar nachts heiß!
5. Im Jahr 2016 hatten wir einen riesigen Monolithen wie den Everest, der viele Ressourcen benötigte. So viele, dass wir manchmal die maximale Größe der für einen bestimmten Host empfohlenen Gastcomputer überschreiten mussten. Der Support hat uns beharrlich gebeten, die Größe der virtuellen Maschinen auf mindestens die Hälfte der Hostgröße zu reduzieren. Wir müssen IT Grad Tribut zollen - uns wurde angeboten, eine separate Hardware zu verwenden, die für ein paar andere große Kosten vollständig verwendet werden kann, und die Flexibilität der Cloud ging verloren.
6. Die monatliche Abrechnung zur Messung des Ressourcenverbrauchs hat uns zweimal einen Streich gespielt. Gleich zu Beginn haben wir direkt nach der Möglichkeit gefragt, die Ressourcen am 14. und 15. eines Monats zu reduzieren, um weniger zu zahlen. Uns wurde direkt geantwortet, dass es so funktioniert. Das erste Mal traf es uns schmerzhaft bei der Übertragung eines Teils des Verkaufs in unsere Cloud. Der menschliche Faktor hat funktioniert - sie haben versucht, alles bis zum 14. schnell zu beenden, dann haben sie es merklich geharkt. Das zweite Mal haben wir diese Gelegenheit nach fast dreijähriger Zusammenarbeit genutzt. Danach wurde uns durchschnittlich am 5., 15. und 20. Tag eine Rechnung gestellt. Dann wirkte der menschliche Faktor für sie - nach dem Anruf stellte sich heraus, dass sie einen Fehler zu ihren Gunsten gemacht hatten (die Neuberechnung erfolgte manuell), entschuldigte sich und gab einen Rabatt.
7. Die Leistung von Festplatten und Maschinen insgesamt entsprach den angegebenen Merkmalen. Trotzdem konnten wir mehrmals nicht verstehen, warum alles so langsam funktionierte, sogar die Benutzeroberfläche wurde gnadenlos langsamer. Der Support versicherte, dass alles in Ordnung war und sie keine Probleme mit der Ausrüstung hatten. Was dort passiert ist - unser Server wurde in diesem Moment auf einen benachbarten Host migriert oder jemand hat ein Backup des Festplattensubsystems durchgeführt -, bleibt uns ein Rätsel.
8. Festplatten können unabhängig voneinander nur durch Unterstützung zwischen Maschinen gewechselt werden. Zu Beginn der Verwendung war es unmöglich, Festplatten unterschiedlichen Typs in der Maschine zu haben, man musste raus (iSCSI, Samba und NFS). Nach einiger Zeit wurde die Verwendung verschiedener Festplattentypen auf einem Computer zuerst durch Support und dann allein möglich (anscheinend in vCloudDirector). Die Aktualisierung des Virtualisierungsmanagementsystems erfolgt übrigens regelmäßig. Wir erhalten 1-2 Mal im Monat einen Brief, in dem angegeben wird, dass das Steuerungssystem der virtuellen Maschine für ein oder zwei Stunden technische Arbeit aufnimmt und für einige Zeit nicht verfügbar sein wird. Die Maschinen selbst arbeiten zu diesem Zeitpunkt weiter.
9. Am 16. Februar 2018 lag ein Teil unseres Umsatzes in IT Grad aufgrund von Stromversorgungsproblemen des Rechenzentrums, in dem sich die Geräte befanden. Wir haben de facto von dem Vorfall erfahren und konnten keinen technischen Support kontaktieren. Ich musste unseren Account Manager anrufen, er sagte sofort in einer Minute was und wie und trennte sich, anscheinend erzählte er den Rest. Vom Angenehmen - wir lagen neben VKontakte.

Nachdem wir einige Zeit in einem gemieteten Haus verbracht hatten und mit all dem konfrontiert waren, entschieden wir uns 2017 für einen guten Besuch, aber besser für zu Hause, und begannen, eine Cloud mit schnellen NVMe-Festplatten und der Fähigkeit zu erstellen, alles vollständig zu steuern. Kaum gesagt als getan: Sie haben den Umsatz in ihre Cloud aus Firmenkunden und Suchmodulen verlagert (insgesamt mehr als 90% der Last) und Überwachung, Statistik und Privatkunden in IT Grad belassen. Im Jahr 2018 rechneten alle erneut und es stellte sich heraus, dass es rentabler war, die Produktion aufzuteilen: Teil der gemieteten Cloud und Teil der eigenen. Was dabei herauskam - erzählen wir weiter.

Mail-Cloud-Lösungen

Ehrlich gesagt wollte ich, wie in AWS, aber in Russland. Aus diesem Grund haben wir begonnen, mit ähnlichen Diensten (die ich zumindest mit dem Analogon von EC2 und S3 täusche) in die Wolken zu blicken. Die Suche war von kurzer Dauer - wir fanden den "russischen Amazonas" in der Person von MCS . Ein großes Unternehmen mit einem breiten Spektrum an vielfältigen Dienstleistungen, die nach allen Angaben in der Lage sein sollten, die Wolken vorzubereiten!

Der Beginn der Bekanntschaft war wunderbar. Ein Account Manager kam in unser Büro, erzählte alles im Detail und beschrieb die aktuellen Möglichkeiten und Pläne für die nahe Zukunft. Die Ausgabe war ein wunderbares Bild: Niedrige Preise für Rechenressourcen, Objektspeicherung und ein früher Ausstieg aus der Datenbankproduktion (ähnlich wie bei RDS). Wir erhielten auch ein solides Bargeldlimit für Tests (sogar mehr als das, was Azure bietet).

Zu diesem Zeitpunkt war der IaC-Teil bereits bereit, alle Maschinen über Terraform bereitzustellen. MCS hatte Openstack und es wurde gut unterstützt! Der technische Support erfolgt übrigens über einen Telegrammkanal - „Live“ -Kommunikation, und es ist klar, dass sie helfen möchten. Es gibt ein Ticketsystem, das wir jedoch noch nicht verwendet haben. Technischer Support SLA bezieht sich auf Anforderungen, die im Ticketsystem erstellt wurden.

Bis Dezember 2018 hatten wir Skripte für die Bereitstellung der Infrastruktur über Terraform geschrieben. Es ist Zeit sich zu bewegen. Zunächst beschlossen wir, das System auf Privatkunden zu übertragen, die die ganze Zeit über auf Geräten in IT Grad lebten. Dann ist alles wie in einem Film:

7 (), 18:00 . , .
10 (), 10:00 – .
12 () – .
10:00 terraform. , , .
12:00 ansible'. . !
15:30 . 30 , 16:30.
15:45 . .
15:55 . : , .
16:20 , . , . , - .
17:30 , , .
18:00 . 1,5 .


Das identifizierte Problem mit verschiedenen Formaten mit einem neuen Versuch sollte nicht aufgetreten sein, aber wir haben es gefunden und für alle Fälle behoben.

17 (), .
15:30 . , .
16:00 . .
16:30 , 100%. -? !
17:00 , , , , iotop, top, ProcessExplorer, PerformanceMonitor. .
21:45 , , , 2000 .
22:00 , .


Das alte Produkt von IT Grad konnte die verzögerte Nachfrage nach Benutzerprüfungen problemlos befriedigen, kein Problem.

Am nächsten Tag (18. Dezember) stellten wir Folgendes fest:

1. Wir wussten nicht, was das System speziell verlangsamte. Vor dem Fries gab es praktisch nirgendwo eine Ladung. Ja, wir haben immer noch tiefe Blockierungsanrufe im System und höchstwahrscheinlich gibt es irgendwo eine Blockierung, aber wo genau, was wir nicht finden konnten, war es notwendig, weitere Untersuchungen durchzuführen.
2. Unser aktueller Belastungstest stimmte nicht mit dem Lastprofil für das Produkt überein. Es war unglaublich, weil Dank dieses Tests haben wir uns auf die letzte Sitzung vorbereitet, eine große Anzahl von Engpässen identifiziert und beseitigt. Dies ist jedoch die Realität - es ist notwendig, den Test unter Berücksichtigung der gesammelten Erfahrungen zu wiederholen.
3. Es wurde auf IT-Niveau mit vergleichbaren CPU- und RAM-Ressourcen hergestellt und kann problemlos die doppelte Last bewältigen.

So haben wir schnell einen Test erstellt, der das gleiche Ergebnis erzielt, das wir aus erster Hand gesehen haben. Wir haben uns an den MCS-Support gewandt, um herauszufinden, ob wir ein CPU-Limit verbrauchen, aber im Allgemeinen liegt es ganz bei uns oder nicht, und mit dem Netzwerk ist alles in Ordnung. Sie haben die zweite Frage immer noch nicht beantwortet, sie haben etwas in der dritten gefunden und uns empfohlen, Änderungen für Multi-Core-Systeme vorzunehmen. Im Allgemeinen haben wir eine lebendige Aktivität entwickelt, das Ende des Jahres ist nahe und jeder möchte mit einem Gefühl der Leistung in die Ferien fahren.

Folgendes haben wir bei der Arbeit mit MCS erreicht:

1. Bereits in der Phase der Auswahl wurde uns eine Tabelle mit den Merkmalen der virtuellen Hardware und der SLA per Festplatte gesendet. Einer der Vorteile war, dass sie 50 IOPS / GB (IT Grad: 30 IOPS / GB) für die SSD versprachen. Der Vertrag stellte sich als anders heraus: „Lesen: 5000 IOPS, Schreiben: 2000 IOPS“, und wir haben dies verpasst, wir haben dies nicht erwartet. Die Tabellen sind identisch, der Unterschied besteht nur an einer Stelle! Die Leistungsabhängigkeiten von der Festplattengröße haben wir übrigens nicht gesehen. Beim Testen stellte sich sogar heraus, dass bei einem größeren Laufwerk die Geschwindigkeit sinkt. Das Geheimnis derart kleiner Indikatoren besteht darin, dass MCS über geografisch verteiltes Ceph verfügt. Dies bedeutet, dass dem Client erst dann mitgeteilt wird, dass die Aufzeichnung abgeschlossen ist, wenn der Remote-Knoten angibt, dass die Daten geschrieben wurden. Übrigens scheint niemand unter den Anbietern, mit denen wir gesprochen haben, eine solche Zuverlässigkeit zu haben. Aber für uns steckt diese Zuverlässigkeit nur in den Rädern! Wenn etwas passiert, müssen wir bei Problemen schnell zu einem anderen DC wechseln, und daher haben wir unsere eigene asynchrone Replikation. Wir haben DRP und sind auf den Verlust einer kleinen Datenmenge im Falle eines Unfalls vorbereitet. Wir müssen MCS Tribut zollen, sie haben die Inbetriebnahme eines lokalen SSD-Arrays beschleunigt, dessen Leistung viel höher war.
2. Die Parameter der Maschinen sind nicht willkürlich. Es gibt einen bestimmten Satz von CPU-RAM- {SSD / HDD} (fast wie in AWS), und andere Maschinentypen können nur durch Unterstützung erstellt werden. Der gesamte Vorgang dauert ca. 2 Stunden, die Anzahl der Typen ist unbegrenzt. Hauptsache, die Anzahl der Kerne sollte nicht mehr als die Hälfte der Hypervisor ~ 40-48-Prozessoren betragen. Während der Maschinenerstellung können Sie selbst Discs hinzufügen und zwischen Maschinen wechseln.
3. Nach dem Einschalten der lokalen SSD war es aufgrund der Änderung der Parameter der Maschine unmöglich, sie zu starten. Sie konnten nur durch Unterstützung gestartet werden. Irgendwann in einem Monat lösten sie das Problem.
4. Zum ersten Mal mit technischer Unterstützung per Telegramm konfrontiert. Im Allgemeinen ist es besonders zu Beginn praktisch, wenn viele Fragen gestellt werden und der Service eingeschränkt wird. Aber je weiter, desto schwieriger stellten sich die Fragen und die Reaktionsgeschwindigkeit und der Informationsgehalt nahmen langsam ab. Am Ende des Jahres, als natürlich alle Fristen eingehalten wurden, machte mich die geringe Reaktionsgeschwindigkeit schrecklich wütend. Irgendwann fragten sie sogar nach SLAs. Hier kam das Verständnis, dass SLA im Ticketsystem und nicht im Telegramm enthalten ist! Zum Zeitpunkt des 19. Februar hängen einige unserer am 24. Dezember gestellten unbeantworteten Fragen in diesem Kanal ...
5. Der technische Support über das Ticketsystem berücksichtigt nicht, dass wir angemeldet sind, und erfordert eine zusätzliche Benachrichtigung über die Vertragsnummer. Als Antwort sendet er einen Brief „Wir werden uns mit Ihnen in Verbindung setzen“, gibt jedoch weder die Ticketnummer noch den Status an.

Während der Arbeit mit MCS begann eine andere Cloud parallel zu schauen.

Noch eine Wolke (Yandex Cloud)

Der erste der anderen war Yandex. Ende 2018 verfügten sie nur über virtuelle Maschinen und Objektspeicher, eine eigene Virtualisierungssystem-Shell und eine offene API. Das Terraform-Plugin war in Alpha und wurde von HashiCorp genehmigt. Die Unterstützung erfolgt wie üblich per Telegramm, ist jedoch weniger aktiv als bei MCS. Das Testgeldlimit ist klein genug und erlaubte uns nicht, normale Tests durchzuführen. Ich musste schnell eine Vereinbarung abschließen (3 Arbeitstage) und für das Testen bezahlen. Den Testergebnissen zufolge haben wir das Gleiche wie beim MCS erhalten. Es schien uns, dass es zwei Probleme gab: Jeder hat zu langsame Laufwerke und wir haben einen zu schweren Test.

IT Grad 2019

Im Allgemeinen haben wir bereits am 22. Dezember eine Frist für den Umzug festgelegt, damit noch eine Woche Zeit bleibt, um die verborgenen Probleme eines neuen Wohnsitzes zu identifizieren und zu lösen. Nachdem wir die Hoffnung auf einen Termin verloren hatten und die Fülle neuer Informationen in der Person von MCS und YC ein wenig satt hatten, entschieden wir, dass IT Grad vor ihrem Hintergrund nicht so schlecht ist. Wir fühlten uns sogar ein wenig nostalgisch und dachten, dass alles Neue gut etabliert und alt ist. Bereits bei IT Grad werden wir auf jeden Fall gut arbeiten - es gibt einen Präzedenzfall. Plus IT Grad aufgepumpt: Es gab ein Moskauer Rechenzentrum, Tier III, dessen Betriebszeit derzeit noch 100% beträgt (nie ausgefallen), und die Ausrüstung im Inneren ist Intel Xeon Scalable mit 4 Sockeln (bis zu 42 Kerne x 3) GHz Xeon Gold 6154). Was zum Teufel nicht scherzt, geben wir eine zweite Chance!

28 (), 18:10 - vDC , , .
29 ( ), 17:04 , . .iso , . , . , . , .
30 (), 22:00 , .iso, . , - .
31 (), 3:15 Edge vDC vDC. , . .

, .

2 (), 15:30 .
2 (), 21:50 , Guest OS Customization .
3 (), 18:05 !

1. Bei der Vorbereitung des Artikels stellten sie nun fest, dass der genaue Zeitpunkt der Anfragen und Antworten nicht im Ticketsystem enthalten ist. Stattdessen heißt es "vor ungefähr 2 Monaten", die genaue Zeit wird nur in einem Tooltip angezeigt. Per E-Mail ist es auch schwierig, die Reihenfolge der Ereignisse wiederherzustellen. Nachrichten an die E-Mail werden in nicht offensichtlicher Logik geliefert und enthalten keine Beschreibung der Aktion. Tickets werden nach einiger Zeit im Auftrag eines Mitarbeiters des technischen Supports von IT Grad im System erstellt.
2. Nach einem genaueren Blick auf die Ausrüstung nach den Ferien sahen wir dort Xeon v2. Darauf haben wir uns nicht geeinigt. Okay, wir haben diese Frage mit dem Account Manager entschieden. Es gab einige Schwierigkeiten aufgrund der Tatsache, dass IT Grad im neuen Jahr 2019 in die MTS aufgenommen wurde und es direkt nach den Ferien ein leichtes Durcheinander gab. Von vDC an war neue Ausrüstung in der Moskauer DC nicht sichtbar. VDC wurde vor dem neuen Jahr erstellt. Nur über das offene Internet hat uns der technische Support „erfreut“, dass die Bewegungsgeschwindigkeit 1 TB / Tag nicht überschreitet. Und wir haben bereits 7 TB Daten hochgeladen! Infolgedessen erstellten sie am Donnerstagabend einen Antrag auf Umzug. Einen Tag später, am Freitagabend, fragte ich, wie geht es dir und wann planen sie zu beginnen (warte fast eine Woche!)? Einen Tag später, am Samstagabend, wurde uns mitgeteilt, dass sich alle Autos bewegt hatten. Ich mochte es nicht, dass 2,5 Tage lang keine Informationen über den Fortschritt der Arbeiten vorlagen und dass die Schätzungen für den Umzug zu pessimistisch waren.
3. Als wir im September 2018 mit der Implementierung von IaC begannen, stellten wir fest, dass Terraform mit vCloudDirector sehr schlecht funktioniert (Aktualisierung: Zum Zeitpunkt des Schreibens haben wir erfahren, dass VMware vCloud Director Provider 2.0 angezeigt wurde, haben es jedoch noch nicht ausprobiert). Zuerst konnten wir nicht einmal eine Maschine erstellen, da vCloud uns über einen Fehler im Sinne von "etwas ist schief gelaufen, Sie haben einen Fehler von 512 Zeichen 136 Zeilen (die Zeile war kürzer!) Xml der Maschinenkonfiguration" informiert hat. Wir haben um Unterstützung gebeten. Die Frage wurde an die Ingenieure weitergeleitet. Am Ende wurde uns mitgeteilt, dass Terraform nicht unterstützt wird - klären Sie es selbst. Wie auch immer, wir haben herausgefunden, dass der Packer schuld war, mit dem wir das Image der Maschine gesammelt haben. Er konnte das proprietäre VMware-Konfigurationsformat nicht bewältigen. Terraform ist mit vCloudDirector sehr schlecht, alles ist langsam Single-Threaded und der Connector wurde für eine lange Zeit verlassen und entwickelt sich nicht. Niemand würde uns Zugang zu vSphere geben. Wenn Sie auf VMware bleiben, müssen Sie Ihre Automatisierung über deren API überprüfen.

Wir haben einen Prüfstand an einem neuen Standort organisiert. Das Ergebnis war erstaunlich - der Test ist fehlgeschlagen, die Symptome sind die gleichen wie beim MCS. Wahrscheinlich wurden im aktuellen Produkt in der Hitze des Kampfes um die Sitzung einige Betriebssystemeinstellungen geändert, die das Einfrieren des Systems verhindern, aber jetzt nicht wiederhergestellt werden können. Um dies zu verhindern, führen wir IaC ein. Wir haben zwei weitere Tests durchgeführt: Neue Maschinen aus sauberen Images der Betriebssysteme des aktuellen Verkaufs erstellt - Fehler; auf bestehenden Produktionsmaschinen - Erfolg. Somit wurde bestätigt, dass wir einige Optimierungen im Betriebssystem oder in der Datenbank vorgenommen haben, aber wir können uns nicht erinnern, welche. Zu diesem Zeitpunkt kam die Lösung aus unserer Entwicklung rechtzeitig: Friese hören auf, wenn zuverlässige Sitzungen in WCF deaktiviert sind.

Wir haben den Auslastungstest mit den von den Entwicklern empfohlenen Einstellungen parallel auf MCS (2 GHz, Xeon v4) und IT Grad (3 GHz, Xeon v2) durchgeführt - die Anzahl der Kerne und des Speichers ist gleich. Bei MCS bestand der Test schneller (um ein Viertel) und reibungsloser (bei IT Grad verlief der Test ruckartig, dann schneller, dann langsamer).

Vergleich der Festplattenleistung

Wir waren am meisten besorgt über die Leistung von Festplatten für Datenbanken und Indizes, weshalb wir hauptsächlich SSDs getestet haben. Beurteilen Sie nicht streng nach Tests, wenn wir die Leistung von Clouds verstehen mussten. Auf habr.com gab es noch keine Tests mit Festplatten, Prozessoren und Speicher ( einmal , zwei ) Cloud-Anbietern. Wir waren zeitlich begrenzt und mussten die Leistung schnell vergleichen, um eine Vorstellung von den Leistungsunterschieden zu bekommen. Daher war die Anforderung für den Test eine - er kann an jedem Ort schnell wiederholt werden. Wir haben die Maschinen so nah wie möglich an den Parametern verwendet, die wir bereits bereitgestellt hatten, fio - um die Leistung von Festplatten zu testen, und pgbench - um die Leistung der Datenbank auf dieser Festplatte zu bewerten. Standardmäßig haben wir Messungen aus der aktuellen Produktion - MARS - vorgenommen (da unsere Ausrüstung nach den Helden der Zeichentrickserie über Mäuse-Rocker vom Mars benannt ist ).

In der Regel hängt die Festplattenleistung von ihrer Größe ab. Wir haben dieses Verhalten in IT City und in AWS beobachtet, aber in MCS haben wir keine solche Abhängigkeit festgestellt, es existiert auch nicht in SLA, und die Tests ergaben ein paradoxes (und möglicherweise ungenaues) Ergebnis - die Leistung nimmt mit zunehmender Festplatte ab.

Wir haben iops für HDD- und SSD-Festplatten sowie tps (Transaktionen pro Sekunde) für die Postgres-Datenbank auf SSD-Festplatten gezählt. In MCS gibt es zwei Arten von Festplatten: normale geoverteilte Ceph-SSDs und -DHDDs sowie lokale SSDs (nur in einem DC) (deren Leistung in Klammern angegeben ist). Ebenfalls im Januar 2019 haben wir im Mailing von MCS gelesen, dass sie die Festplattenleistung um 20% gesteigert haben. Das Testergebnis ist ebenfalls in der Tabelle enthalten (MCS 2019). Im Februar wurde eine weitere Beschleunigung gemeldet, aber wir haben hier keine Tests durchgeführt.

Ergebnisse:

Testmethode

iops wurde als Durchschnitt von 4 fio Läufen berechnet:
/root/fio-2.0.9/fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75

tps , durchschnittlich 3 pgbench läuft:
pgbench -c 10 -j 2 -t 10000 example

Beschreibung der Stände

Mars

Xeon v4, 2 GHz ; HDD: Ceph, 3 Knoten von 9x 2 TB ST2000NX0253, Replik 2; SSD: Ceph, 3 Knoten auf 2 TB NVMe Intel DC P4600, Replik 2

CPU : 4, RAM : 8 GB, Festplatte : 32 GB, SSD : 150 GB; Die parallele Produktion dreht sich.

IT Grad

Xeon v4 / v2, 2 GHz ; Festplatte : 0,1 IOPS / GB ; SSD: 30 IOPS / GB

CPU : 4, RAM : 4 GB, Festplatte : 250 GB, SSD : 200 GB

Mcs

Xeon v4; Festplatte: r / w: 1500/1000 IOPS; SSD: r / w: 5000/2000 IOPS

Zum Testen von Festplatte: CPU : 2, RAM : 4 GB, Festplatte : 50 GB

Zum Testen von SSD, TPS : CPU : 8, RAM : 16 GB, SSD : 600 GB

Y

Xeon v4, 2 GHz

CPU : 8, RAM : 8 GB, Festplatte : 20 GB, SSD : 50 GB

Vergleich der TCO-Schätzungen für das Jahr

Wir haben die Gesamtbetriebskosten für vier Optionen gezählt. Relative Werte sind in der folgenden Tabelle aufgeführt. Ich muss sagen, dass dies eine Berechnung für unseren speziellen Fall ist und alles für Sie anders ausfallen kann.

Wir haben die Berechnung wie folgt durchgeführt. Das Jahr war in zwei Teile gegliedert: Sitzungen (mit erhöhter Arbeitsbelastung) und den Rest der Zeit. Für jeden Teil wurde die erforderliche Menge an CPU- und RAM-Ressourcen berechnet. Das erforderliche Festplattenvolumen wächst aufgrund des stetigen Wachstums des Dienstes nur mit der Zeit. Daher haben wir den Durchschnitt zwischen Anfang und Ende des Jahres zur Bewertung herangezogen.

Es gab wenig Schwierigkeiten bei der Bewertung mit AWS, as Es gibt keine direkten Kosten für den Kernel und Gigabyte Speicher. Wir haben 3 minimale Maschinen c5.large, r5.large und m5.large genommen und ihre Kosten zu MCS-Preisen berechnet (proportionale Änderung der Kosten des CPU-Kerns, da MCS eine Frequenz von 2 GHz hat). Es stellte sich so heraus: Im Durchschnitt sind die Kosten für einfache AWS-Instanzen 2,5- bis 2,8-mal höher als die Kosten für MCS. AWS veröffentlicht Preise ohne Mehrwertsteuer. Für die Kosten von AWS, die wir um 20% addieren, beträgt der durchschnittliche jährliche Dollarkurs 70 Rubel. Festplatten werden ganz einfach zu EBS-Preisen betrachtet (wir verwenden verschiedene Arten von gp2, sc1, st1). An einigen Stellen benötigen wir NVMe-Laufwerke aus Instanzen der i3-Familie. Ihr Preis pro Gigabyte wird sehr einfach berechnet: Die Differenz der Kosten zwischen i3 und einer analogen Prozessor- und Speicherinstanz der r4-Familie, geteilt durch die Menge an NVMe. Es stellt sich heraus, 3,1 Rubel pro Gigabyte in 30 Tagen.

Selbst im Gespräch über Budgets möchte ich den Unterschied in den Kosten einer Windows-Lizenz für einen Kern pro Monat für alle Cloud-Anbieter feststellen. Unter AWS beträgt der Unterschied zwischen den Kosten für Linux OnDemand- und Windows OnDemand-Instanzen geteilt durch die Anzahl der Kerne eine Konstante von etwa 2.800 Rubel pro Monat. In YC ist die Windows-Lizenz für den Kernel dreimal billiger, ungefähr 900 Rubel pro Monat, und in MCS fast 9 (!) Mal billiger, ungefähr 300 Rubel pro Monat. Wir sind immer noch sehr abhängig von Windows: Dank des .net-Kerns beginnen wir nun, Anti-Plagiate plattformübergreifend zu gestalten, einschließlich der Reduzierung der Wartungskosten.

Die Gesamtkosten von YC umfassen auch die Verkehrskosten.

Schlussfolgerungen

Durch die Wolken

AWS Sie sagen, dass es in Russland 4 gute Cloud-Anbieter gibt: AWS, GCP, Azure und DO, und alle sind nicht in Russland.
Vorteile: großartiger Service, hochwertige moderne Ausrüstung, gute Konfiguration in EC2, eine große Anzahl von Services.
Nachteile: teuer (plus Wechselkursrisiken) und nicht in Russland (ILV, die große russische Firewall am Horizont). Ich möchte wirklich, dass unsere Wolken diesem Beispiel folgen.
Features: Kostenloser technischer Support kann ein Minimum an Problemen lösen, aber um ehrlich zu sein, haben wir ihn nur kontaktiert, um die Nutzungsbeschränkungen zu erweitern. Bezahlt kostet übrigens ca. 10% des Kontos.

IT Grad . Guter Service für die Corporate Cloud. Es gibt Analoga von EC2 und S3, die auf Swift basieren.
Vorteile: gute Leistung (1-2-3 GHz CPU, SSD, HDD), frische Ausrüstung (in einem der DCs) in den heimischen Clouds, beliebige Maschinenkonfigurationen.
Nachteile: unverständliche Abrechnung, VMware (schlecht automatisiert, Flash-Schnittstelle), ein bisschen Chaos und technische Probleme.
Funktionen: Bei Verwendung im Unternehmen stärker geschärft (einmal konfiguriert, dann seltene Änderungen) als bei einem stark ausgelasteten öffentlichen System (häufige Aktualisierungen, ständige Änderungen). Seit 2019 wird das IaaS-Geschäft zusammen mit Mitarbeitern und Ausrüstung bei MTS verkauft. Jetzt kann sich alles in jede Richtung ändern. Kommunikation über das Ticketsystem und Telefon, ich möchte eine schnellere Reaktion und Nachricht über die erwarteten Fristen.

MCS . Es gibt Analoga von EC2-Diensten (es gibt GPUs), S3, ECS, RDS, EMR und eigenen Diensten: Maschinelles Lernen, Cloud Disaster Recovery, Cloud Backup
Vorteile: kostengünstig, aktiv entwickelt, es gibt GPUs (Tesla V100 und Grid K2).
Nachteile: langsame Fahrten, feuchtes, schlechtes Karma von der Muttergesellschaft.
Features: Technischer Support zu Beginn ist nützlich, eine große Anzahl von Mitarbeitern ist eingeschaltet, Hilfe ist zu spüren, aber dann gibt es einen spürbaren Rückgang der Aktivität (sie haben seit dem 24. Dezember nichts mehr beantwortet, ich mache mir sogar Sorgen um die Jungs).

YC . Wir haben sehr wenig Erfahrung mit diesem Anbieter, es ist schwierig, etwas Spezifisches zu sagen. Es gibt Analoga von EC2, S3, RDS, DS, SQS (alfa), ELB (alfa), deren einzigartige Dienste: SpeechKit, Translate.
Vorteile: Laufwerke sind schneller als MCS.
Nachteile: Der Anbieter von Terraform ist feucht; Die Software der Virtualisierungs-Shell mit offener API ist für die Community nicht sehr groß, was bedeutet, dass Sie sich bisher nur auf die Stärken des YC-Teams bei der Entwicklung des Anbieters für Terraform verlassen können.
Features: für den Verkehr bezahlen.

Lektionen gelernt

1. Wir haben festgestellt, dass Stresstests moralisch überholt sind. Sie haben den Test aktualisiert, neue Engpässe festgestellt, behoben und das Produkt verbessert. Wir haben uns daran erinnert, dass der Belastungstest angemessen sein sollte und es Konfigurationen geben sollte, die definitiv nicht bestanden werden, damit Sie die Grenzen seiner Anwendbarkeit erkennen können.
2. Trotz der weit verbreiteten Überzeugung, dass Software derzeit nicht optimiert wird und dass alle Engpässe mit Ressourcen überflutet werden, mussten wir unser System herausfinden und optimieren. Es stellte sich heraus, dass die neue Version von Anti-Plagiat weniger Ressourcen benötigt und schneller arbeitet. Es wurden bereits mehrere weitere Stellen beschrieben, an denen Sie den Ressourcenverbrauch senken können.
3. Wir haben IaC, Bereitstellung und Aktualisierung über Ansible durchgeführt und gelernt, wie man in fast 10 bis 15 Minuten von Cloud zu Cloud (mit vorläufiger Datenreplikation) wechselt. Wenn die Daten kopiert und die reguläre Replikation konfiguriert ist, handelt es sich hier um einen Notfallwiederherstellungsplan: Verschieben in einer halben Stunde mit Datenverlust in den letzten 15 Minuten.

Was wir von den Wolken wollen

1. Schnelle Antworten vom technischen Support. Leider können wir es bisher nicht wie in AWS verwenden - es sind zu wenig Informationen verfügbar.
2. Unterstützung bei der Automatisierung der Infrastrukturbereitstellung durch kostenlose Mittel (Terraform).
3. Vorhersehbarkeit der Leistung. Dies gilt für Abrechnung, CPU-Leistung, RAM, Festplatten.
4. Das Vorhandensein der funktionellen Analoga EC2, S3, RDS jetzt. In naher Zukunft benötigen wir Unterstützung für k8- und GPU-Berechnungen (wir verwenden sie bereits in AWS).

In den letzten Monaten haben wir es nicht nur geschafft, uns zu den Wolken zu bewegen, sondern auch den Rechen in anderen Bereichen zu berühren. Wie es war - wir werden es später erzählen.