Myslím, že vím co se chce, asi jsem to měl více rozepsat nebo to takto neuvádět bez kontextu.
Stávající systém běží v cloudu, garanci mají 99,99 %, v noci se dělá snapshot celého serveru, jsou k dispozici 2 po sobě, databáze je replikována na jiný server v jiném geografickém umístění. Kdyby ten virtuál klekl a nešel ani spustit, tak spuštění ze zálohy otázka minut a dosypání dat z repliky je na pár desítek minut. Takto to funguje, vyhovuje to a nový systém bude podobný. Nakonec my takovou spolehlivost negarantujeme, při aktualizaci Windows jednou za měsíc stejně na pár minut až desítek minut nejede, než se restartuje. To není problém, je to o víkendu a v noci, kdy je relativně klid.
Těch 10 sekund uvedu na příkladu - když byl před léty systém několik hodin přetížený, tak odezva databáze byla třeba 10-20 sekund. A protože na ten server komunikují desítky jiných systémů a stále něco požadují, tak ty odpovědi trvaly a začalo to vadit.
A to je v podstatě to, čemu bychom chtěli předejít. Takže třeba web bude ukládat do hlavní DB a číst z repliky. Kdyby se stalo, že web bude vyčítat takové množství dat, že DB přetíží, tak to až tak vadit nebude, hlavní DB pojede dále.
Další věcí je zvýšení bezpečnosti, kdy nyní máme vše na jednom serveru, což nějak necítím jako dobré řešení. V neposlední řadě jde například o lepší způsob aktualizace jednotlivých částí, bez větších výpadků. Např. DB se musí zastavit, aktualizovat, spustit, migrovat atd. a to nějakou dobu trvá. Kdyby byly 2 DB servery v dockeru, spustí se replikace na novou verzi a pak se to jen přepne - skoro bez výpadků.
A nakonec chceme použít Keycloak a ten je výhodné provozovat v Dockeru, novou verzi si připravíme mimo, spustíme kontejner a přepneme.
Když se vrátím k prvnímu postu, tak mi fakt jde o zorientování se v tom, kdy třeba použít docker a na co více virtuálů.
Už hledám DevOps konzultanta.
16 Odpovědí
6427 Zhlédnutí