Jak jsme migrovali

Jak jsme migrovali

Za posledních šest let jsme migrovali naši službu už několikrát. Začínali jsme na vlastním hardwaru v Coolhousingu, který jsme později přesunuli do Master DC. Odtamtud jsme se posunuli na Scaleway, abychom během půl roku přešli na DigitalOcean. Z něj jsme se v uplynulém víkendu přesunuli zpět do Master DC, tentokrát na pronajatý hardware značky Dell.

Z pohledu vás, uživatelů, jsme s migrací začali po jedné hodině ráno v sobotu 30. ledna, ale příprava začala už tři týdny před tímto datem. Museli jsme:

  • Upravit NodeAPI, aby podporovalo bind HTTP a SSH portů na různé IP adresy a
  • konfigurovatelný adresář, ve kterém mají aplikace uložena data,
  • museli jsme nastavit síť, protože databáze a aplikace jsou teď na jednom serveru,
  • šifrování mezi tímto novým nodem a loadbalancerem je uděláte trochu jinak a museli jsme odladit konfiguraci,
  • a nakonec jsme připravili checklist, podle kterého jsme pak jeli během samotné migrace,
  • a také checklist, co dělat, až bude vše hotovo.

Proti jiným migracím šla tahle docela bez problémů. Hned z kraje se nám podařilo narazil na limit tasků v systemd, který byl zaveden ve verzi systemd, která je dostupná v Debianu. Byl to tak velký problém, že nám to rozbilo docker a museli jsme začít vytvářet všechny kontejnery znovu. Čas, kdy byla služba dole, to protáhlo asi o hodinu.

Během nahazování kontejnerů jsme narazili na nekompatibilitu jednoho staršího image (rosti/php:5.4) a Debianu 10, resp. jádra 5.9. Debian 10 je tak pravděpodobně poslední pro všechny image před našimi Runtimes. Také jsme si všimli, že tyto starší image používají starší formát docker obrazů, který nemusí být podporován v dalších verzích Dockeru. Obojí je něco, s čím si budeme muset během příštích dvou let poradit. Dnes už nemáme žádný server na Debianu starším než 9, který má podporu až do roku 2022 a hned jak na to bude chvilka, tak přemigrujeme i těch pár zbývajících na desítku.

Možná jste si všimli, že administrace byla v posledních týdnech trochu pomalejší než obvykle. Nejdříve jsme si mysleli, že je to způsobené tím, že NodeAPI, přes které administrace pracuje s aplikacemi, není úplně optimalizované na 450 kontejnerů na jednom serveru, ale nakonec to nebylo ono. Po přestěhování administrace z Kubernetes na vyhrazený server problém zmizel. Administraci jsme nakonec stěhovali na rychlo, protože jsme si neuvědomili, že jsme ji migrací odstřihli od databází a tak nebylo možné databáze přidávat ani měnit hesla u těch současných.

Další problém máme s naší Grafanou, kde náš dashboard úplně nezvládá vykreslit najednou data ze 450 síťovek. Monitoring obecně je docela problematický. Aktuálně server monitoruje Telegraf, node_exporter pro Prometheus a cAdvisor a všechno tohle dohromady je většina zátěže na celém stroji.

Začátkem roku jsme přešli na Prometheus, takže s node_exporterem nic neuděláme a ten zůstane. Telegraf posílá data o kontejnerech a systému do InfluxDB, ze kterého pak Administrace vykresluje grafy pro aplikace. Tyto grafy budou brát data z Promethea, takže Telegraf i InfluxDB budeme moc odstřelit.

Co aktuálně nemáme jak nahradit je cAdvisor. Je to nástroj od Googlu, který exportuje data o kontejnerech a v tomto počtu kontejnerů vyžaduje neúměrné množství procesorového času. Nebál bych se říct, že víc jak polovina současného loadu patří právě tomuto nástroji. Rozhodli jsme se tedy tu část, která sbírá data, implementovat do našeho NodeAPI, který aktuálně sbírá data o využití paměti a disku a jen tam přidáme ještě data o využití procesorového času, sítě a blokových zařízení. Grafy ke všem zmíněným datům bychom rádi zobrazili v administraci.

Největším problémem této migrace ale byla databáze store3. Minulý rok jsme všechny databáze přesunuli do kontejnerů, ale na store3 běželo PostgreSQL jak v kontejneru tak mimo něj a aktivní instance byla ta mimo. Toho jsme si teď nevšimli a zkopírovali tak skoro rok stará data, o kterých jsme ani nevěděli, že je tam máme. Naštěstí šlo o databázi, kterou využívají jen jednotky aplikací, takže nebylo tak složité tento problém vykomunikovat s postiženými uživateli.

Nakonec jsme měli ještě problém se starou MongoDB databází a dvěma MariaDB databázemi, které běží úplně mimo systém.

Migrace trvala přibližně dvě hodiny a třicet minut a po této době běželo 99 % aplikací na novém hardwaru. Pokud bychom neudělali na začátku chybu s dockerem, pravděpodobně bychom byli hotovi po hodině a kousek. Musíme teď upravit zálohování, abychom mohli využít toho, že máme aplikační data na Btrfs a nastavit synchronizaci dat do DigitalOcean, abychom v případě problému mohli spustit službu z jiné lokality a také máme pár serverů, které je potřeba uklidit.

Úvodní obrázek je od Kranich17 z Pixabay.