Odo.lv serveris atjaunots uz Ubuntu 16.04 un XWiki 8.4

Kā standarta Ubuntu lietotājs, reizi četros gados esmu spiests pāriet uz jaunāko atbalstīto Ubuntu LTS (t.i. Long Term Support — ilgās uzturēšanas) versiju. (Lai arī ilgās uzturēšanas versijas Canonical izlaiž pāra gados, es uz jaunu versiju pāreju praktiski gadu pēc tam, kad iepriekš-iepriekšējo versiju pārstāj uzturēt, bet jaunāko citi ir pārbaudījuši jau veselu gadu.)

Iepriekšējo reizi odo.lv vietni "vienkārši" atjaunoju no Ubuntu 8.04. uz Ubuntu 12.04, pie reizes atjaunojot arī vietnē izmantoto XWiki satura pārvaldības sistēmu u.c. rīkus. Šoreiz lieta bija nopietnāka, jo esmu paredzējis laist pensijā teju 10 gadus veco fizisko Dell PowerEdge R200 serveri un tā vietā nolēmu izmantot kādu virtuālo serveri. Praktiski salīdzinot šobrīd citos serveros izmantoto Sigmanet VPS, ar testa serveriem iekš Google GCP un Amazon EC2, nolēmu izmantot Amazon EC2.

Tā progresīvajā pasaulē pārbuferētības (bufferbloat) problēma ir praktiski atrisināta un serveru atbildes (precīzāk, datu pārraides laiks) ir pietiekami īss, par to, ka serveris neatrodas Latvijā es vairs īpaši neuztraucos. Tāpēc manu izvēli, galvenokārt, noteica pakalpojuma cena un iespēja pašam pārvaldīt serveru tīkla pieslēgumu (maršrutēšanu un atvērtos portus). Manuprāt Amazon EC2 ir piemērotākā cena ar pietiekami labu pārvaldību, Google GCP ir ērtāka pārvaldība, bet uzturēšanas izmaksas lielākas, savukārt Sigmanet VPS ir gan salīdzinoši augsta cena, gan tīkla vides pārvaldība notiek, tikai sazinoties ar viņu administratoriem (nemaz nerunājot par, piemēram, DEAC kuru cena un patstāvīgas pārvaldības iespējas ir vēl nepievilcīgākas).

Pie jaunā servera uzstādīšanas ķēros Lielās piektdienas vakarā ar domu, ka Lieldienu brīvdienās, kad "normāli cilvēki" datorus lieto mazāk, ar visu tikšu galā. Servera operētājsistēmas uzstādīšana lielas grūtības nesagādāja. Grūtāk gāja ar pāriešanu uz jaunāko XWiki versiju, jo, lai nebūtu konfliktu ar pārvaldības sistēmai nepieciešamajām lapām, nācās tīrīt *.xar failā eksportēto saturu, ko vispirms mēģināju un baudīju lokālā XWiki uz sava datora.

Lai nu kā, ap Pirmajām lieldienām servera tīmekļa daļa un arī lietotāju dati bija pārmigrēti. Bija patīkami redzēt, ka starp LU MII un Amazon Frankfurtes datu centru puslīdz darbojas gigabita ezernets.

Nedaudz nācās papiņķerēties ar IPv6 atbalstu, kas Amazon serveriem (atšķirībā no Sigmanet un Google) pēc noklusēšanas nav ieslēgts. Dažas dienas nācās gaidīt uz reversā DNS ieraksta pieprasījuma izpildi e-pasta serverim.

Lietotāju /home mapei izmantoju LVM disku. Kad pēc Lieldienu brīvdienām pārbaudīju, kas notiek ar jauno serveri, biju nepatīkami pārsteigts, ka tas knapi kust un sistēmas noslodze ir pāri 10. Kad sīkāk izpētīju, kur īsti vaina, atklājās, ka pie vainas ir /home sadaļai atvēlētais disks, kura pieprasījumu atbildes laiks iesniedzās pat 10 sekundēs (ja kādam tas neliekas šausminoši, tad paskaidroju, ka tas ir 1000× lēnāk nekā parasti un ka šādus pieprasījumus diskam operētājsistēma var veikt tūkstošiem reižu sekundē):

Pirmā cilvēcīgi dabīgā vēlme bija lamāt Amazon, bet, kad papētīju sīkāk, atklāju, ka, neiedziļinoties tehniskos smalkumos esmu izvēlējies lētāku diska veidu sc1, kura nosaukumā parādās Cold HDD. (Sevis attaisnošanai varu piebilst, ka pirmo testa serveri izveidoju ar "vecās paaudzes" EBS Magnetic disku, kuram šādus dīvainības nenovēroju.) Lai arī Amazon sc1 sauc par "disku", manuprāt, tā ir ar diskiem kešota lenšu iekārta, kura deklarētajā ātrumā strādā tikai, lasot/rakstot lielus, secīgas piekļuves failus. Savukārt, ar daudziem maziem failiem tā darbojas tik ātri, cik ātri lenšu iekārta var atrast vajadzīgo vietu lentē.

Nolēmu pamēģināt LVM iespēju pievienot jaunu disku un pārkopēt datus gaitā. Izveidoju jaunu st1 Throughput Optimized HDD disku, pievienoju to LVM sējumam, un tad, saskaņā ar aprakstu screen sesijā ievadīju komandu:

Kad pēc 6 stundām process bija ticis līdz 11% biju paspējis izstudēt, ka LVM diska satura pārvietošana darbojas kā pilna diska bloku kopēšana un tad noņemamā diska atslēgšana. Tā kā avota disks bija ļoti lēns, tad pasākums protams bija nepanesami ilgs. Sapratu, ka to gaidīt nav vērts un ka ātrāk būs izveidot jaunu, tukšu disku un lietotāju datus pārkopēt no vecā servera, papildinot izmaiņas no Amazon S3 krātuves.

Failu kopēšanas laikā noskatījos  BBC Horizon 2002 Rogue Wave un Фильм второй. Ю. Гагарин. 40 часов, которых не было.

Disku maiņā man bija jāatrisina viena problēma — pieteikšanās serverim ar SSH. Pēc noklusēšanas Amazon autentifikācijai izmanto atslēgu apmaiņu, bet lietotāja atslēga, protams atrodas /home/ mapē, kuras saturs, atmontējot disku, būtu tukšs. Tāpēc es, drošības labad, ieslēdzu arī pieteikšanos ar paroli un izveidoju īslaicīgu /home/valdis mapes satura kopiju uz / sadaļas diska. Kad biju pārstartējis serveri uzmontējis jaunu LVM disku sējumu ar "kārtīgu" st1 disku, sāku kopēt datus. 

Ap 5 rītā failu kopēšana uz jaunā diska bija pabeigta, un, lai pārliecinātos, ka viss darbojas pareizi, pārstartēju serveri. Pēc daudzu mokoši garu minūšu gaidīšanas, serveris atbildēja uz ping pieprasījumiem, bet tas neatsaucās ne uz tīmekļa pieprasījumiem, ne arī uz SSH portu.

Grūti teikt, ko īsti biju izdarījis nelabojami nepareizi un cik daudz tajā bija mana vai Amazon vaina (ja neskaita to, ka Amazon servera lokālajai konsolei nodrošina tikai skatīšanos, caur kuru tāpēc nevar neko izlabot). Bet bija skaidrs, ka tālāk tā turpināt nedrīkst, un nolēmu iet gulēt.

Kārtīgam sisadminam neejošs serveris sāp vairāk nekā caurs zobs. Tāpēc pēc nepilnas stundas murgaina miega jutos pietiekami atguvies, lai ķertos klāt un izveidotu jaunu un skaistu serveri.

Pirmā atziņa, ko guvu ar apskaidrotu prātu bija tā — labi, ka, neskatoties uz sarežģītajiem manevriem, man pietika laika (un saprāta) veidot rezerves kopijas. Tās gan nebija ļoti aktuālas (dienu vecas), bet man bija saglabāti gandrīz visi pieraksti serveru iestatījumos u.c rīkos.

Otrā, atziņa, ir tā, ka sapratu, piemēram, Amazon EC2 ugunssienas vērtību. Ja kaut kādas kļūdas dēļ es iestatu nepareizi servera  Iptables vai Ufw ugunssienu, tad (ja nelieto servera t.s.  snapshots — momentuzņēmumus), tam  vairs nekādi nevar tikt klāt. Ja kaut ko izdara nepareizi Amazon ugunssienā, tās tīmekļa saskarne saglabājas kā papildu pārvaldības kanāls, caur kuru nepareizus iestatījumus var atjaunot. (Es gan šobrīd tik un tā esmu visu atļāvis Amazon ugunssienā un izmantoju Ufw uz servera, jo tā ir mazāk jāmācās jauni rīki).

Kopumā, atsaucoties uz savu pieredzi, veidojot jaunu serveri, visiem iesaku:

1. Atstāt veco serveri darboties, un pārslēgt lietotājus uz jauno serveri, izmainot DNS ierakstus (piemēram, *.lv domēnam NIC sistēmā, bet, ja serverim ir tikai IP adrese, apziņot lietotājus par adreses maiņu).
2. Detalizētu (vēlams, vizualizētu) sistēmas pārraudzību (piemēram, ar Munin).
3. Lokālu un attālinātu rezerves kopiju veidošanu (piemēram, ar Dar, Mysqldump un Rsync vai AWS).

Otrs servera izveides piegājiens labi pierādīja, ka IT nozare ir zināšanu ietilpīga nozare. To, ko pirmajā reizē man izdevās paveikt vairāku dienu laikā, otrajā reizē es atkārtoju dažās stundās. Lai arī rīkus liku, izpildot komandas, tik un tā laiks, lielākoties, pagāja, vienkārši gaidot failu kopēšanu un atarhivēšanu.

Lai arī tīmekļa lapas darbību atjaunoju vēl pirms 8 no rīta, vēlāk uzzināju, ka daži tik un tā bija pamanījuši, ka odo.lv vietne nedarbojas. Ar e-pasta darbības atjaunošanu veicās grūtāk, jo tajā ir vairāk iesaistītu servisu, kurus mēģinājumos ar pirmo serveri nebiju pietiekami dokumentējis. Tāpēc nācās pavadīt diezgan laika "atceros, ka tur kaut kas bija..." meklējumos, tajā skaitā ilgs klupšanas akmens bija Postfix mynetworks iestatījumi, kuros bija jānorāda servera privātā adrese, jo Amazon serveri atrodas privātā tīklā aiz NAT.

Sarežģīts serveris, tāpat kā Rīga, nekad nav gatavs. Bet, ja neskaita daudzus sīkumus, galvenās lietas šobrīd ir izdarītas, tajā skaitā:

1. Esmu pārliecinājies, ka diska veiktspēja ir pienācīga un aizture nepārsniedz dažus desmitus milisekunžu.

   

2. Esmu atjaunot uzstādīšanas, aprakstus:
   • Serverim uzstādīta 64-bitu Ubuntu 16.04 LTS versija (uzstādīšanas apraksts nav atjaunots, jo izmantojot virtuālos serverus, tas pašam vairs nav jādara, daži pielāgojumi šeit.
   • SSH Apache, Tomcat un MySQL servisi.
   • Kā Apt pakotne uzstādīta XWiki 8.4.4 LTS versija ar adrešu īsināšanu.
   • Postfix un Dovecot e-pasta servisi, ieskaitot Postgrey vēstuļu filtru.
   • Servera pārraudzība ar Munin, Awstats un Piwik.
   • Tiny-tiny-RSS ziņu apkopotājs.
   • Rezerves kopiju veidošana ar Dar un pēc tam kopēšana uz S3.

Vēl īsti nedarbojas:

• Spamassassin vēstuļu filtrs.
• Nav pilnībā pielāgots XWiki stils, Awstat pārskatu stils, un veikti citi sīki pielāgojumi.