🥇Thin provisioning ng mga file system LinuxPaano Gumawa ng mga Gumaganang Kopya ng isang Three-Terabyte MySQL Database sa loob ng 20 Segundo

Ako si Yuri, at ako ang pinuno ng systems administration team sa Citymobil. Ngayon, ibabahagi ko ang aking karanasan sa paggamit ng thin provisioning technology para sa mga file system. Linux Ipapaliwanag ko kung paano ito mailalapat sa mga proseso ng CI/CD ng isang kumpanya. Susuriin natin ang isang sitwasyon kung saan, upang awtomatikong masubukan ang code kapag inihahatid ito sa produksyon, kailangan natin ng mga read-write na kopya ng isang MySQL database na malapit sa bersyon ng produksyon hangga't maaari.

Panimula: Bakit nagbibigay ng masamang payo?

Isang lohikal na tanong, dahil may mga napatunayang mekanismo para sa paglipat ng mga schema ng database sa mga kapaligiran ng pagsubok. Bakit kahit na palawakin ang pangunahing non-sharded DBMS sa mga naturang volume? At hindi lahat ng data ay kailangan para sa pagsubok. Susubukan kong ipaliwanag.

Humigit-kumulang isang taon na ang nakalipas, sa background ng aktibong paglago ng aming aggregator ng taxi (noong 2018, tumaas ang mga natapos na biyahe nang humigit-kumulang 15 beses), tumaas ang dami ng data, ang load sa mga server, at ang dalas ng mga rollout. Natagpuan namin ang aming sarili sa sumusunod na sitwasyon:

Ang pangunahing database ng MySQL ay lumago sa humigit-kumulang 1000 mga talahanayan na may kabuuang 2,5 TB, at patuloy na lumago.
Walang paraan upang mabilis na maging sharded at sirain ang base. Hindi ito pinahintulutan ng lumang diskarte na "Isinulat ko sa database kung ano ang gusto ko at kung paano ko gusto", isang grupo ng mga JOIN at mga internal na dependency sa talahanayan.
Walang mekanismo para sa paglipat ng database schema sa mga kapaligiran ng pagsubok.
Walang awtomatikong pagsubok ng code sa panahon ng pag-deploy.

Nais kong lutasin ang huling problema sa lalong madaling panahon. Ang mga postman test ay naisulat na upang subukan ang pangunahing PHP monolith, ngunit kulang ng isang napapanahon na database. Kasabay nito, hindi kami makakagawa ng replica sa gabi, gawin itong master at iwanan itong mapunit sa araw: napakaraming bilang ng mga rollout at pagbabago, kasama sa data at database schema, ang nagawa sana. ang kinatatayuan ay hindi na mapapagana sa kalagitnaan ng araw. At ang paglilimita sa mga rollout sa isang araw ng trabaho ay hindi magiging epektibo.

Gayunpaman, natapos ang gawain: natanggap namin ang unang working stand sa loob ng dalawang linggo. Ito ay dumaan sa maraming pagbabago sa nakaraang taon at patuloy na ginagamit.

Susunod, ilalarawan ko nang detalyado ang lahat ng mga hakbang at yugto ng pagbuo ng aming solusyon. Makikita mo na ang pamamaraang ito ay karapat-dapat sa karapatang umiral.

Ano ang "thin redundancy"?
Ito ay isang hardware o software na teknolohiya (isa pang pangalan ay kalat-kalat na volume) na nagbibigay-daan sa iyong maglaan ng higit pa sa kinakailangang mapagkukunan kaysa sa magagamit. Sa kasong ito, dapat matugunan ng inilalaang dami ang pamantayan ng sapat na makatarungan (hangga't kinakailangan) at tamang-sa-oras (para sa kinakailangang oras). Karaniwan, ang manipis na reserbasyon ay ginagamit sa iba't ibang mga sistema ng imbakan upang magbigay ng espasyo sa disk sa mga kinakailangang volume, na lumalampas sa mga aktwal na magagamit. Ang teknolohiya ay sinusuportahan ng iba't ibang mga file system, halimbawa, LVM2, ZFS, BTRFS. Ito ay malawakang ginagamit sa virtualization hypervisors. Pinahintulutan kami ng manipis na backup na mabilis na gumawa mula sa mga snapshot ng pangunahing seksyon na may data na kasing dami ng mga kopya ng seksyong ito hangga't kailangan namin (direktoryo ng data ng MySQL DBMS).

Unang stand, Thin LVM technology

Ang kabanatang ito ay maaari ding tawaging “Paano gumawa ng pinakamabilis na mga snapshot ng malalaking volume ng data gamit Manipis na LVM, na binabawasan ang katatagan ng file system at ang MySQL DBMS sa mga malaswang antas."

Dahil nagamit na namin ang LVM para bumuo ng mga pangunahing partition ng OS, nagpasya kaming magsimula dito. Upang magsimula, kailangan namin ng isang hiwalay na pisikal na makina - isang replika ng aming pangunahing MySQL database, kung saan maaari kaming lumikha ng snapshot ng replika kapag hiniling at itaas ito sa tabi ng isang hiwalay na halimbawa ng MySQL. Sa panahon ng pagsubok, pinahintulutan naming gamitin ang mga pagpapatakbo ng pagbabago sa pagkakataong ito, at nang makumpleto ang mga pagsubok, ligtas naming tinanggal ito. Ang configuration ng server ay ganito:

2 x Intel Silver 4114 (10x2,2 GHz HT)
8 x 32 GB DDR4
8 x 1920 GB Intel SSD sa Adaptec RAID controller sa RAID-10

Maaari kang magsulat ng isang hiwalay na artikulo sa paksa ng pagpili sa pagitan ng RAID controller at software RAID MD. Sabihin ko lang na ang aming pagpili ay naiimpluwensyahan ng dalawang salik:

Sa oras na nabuo ang problema, na-install namin ang lahat ng DBMS sa RAID controllers, kaya masasabi namin na nangyari ito sa kasaysayan.
Ang pagkakaiba sa pagganap sa pagitan ng mga synthetic na file system na mga pagsubok at mga pagsubok na may iba't ibang mga operasyon ng MySQL ay minimal.

Hinati namin ang resultang RAID-10: gumawa kami ng iisang Volume Group (VG) para sa buong volume (na may overhead na humigit-kumulang 6,7 GB) at gumawa ng logical partition (Logical Volume, LV) para sa 50 GB system. Sa isang normal na sitwasyon, tinukoy namin ang natitirang espasyo bilang seksyon ng MySQL. Ngunit kailangan namin ng manipis na backup, kaya lumikha muna kami ng isang tinatawag na pool, sa loob kung saan lumikha kami ng isang seksyon para sa /var/lib/mysql na may 3,5 TB (batay sa tinantyang dami ng database):

lvcreate -l 100%FREE -T vga/thin
lvcreate -V 3.5T -T vga/thin -n mysql

Na-format namin ang partition sa ext4, na-mount ito, nag-record ng replica at nakuha ang orihinal na stand. Pagkatapos ay gumawa kami ng isang binding sa anyo ng isang API, na dapat lumikha ng mga snapshot, itaas ang isang MySQL database instance sa isang ibinigay na port at tanggalin ang nilikha na instance. Dahil eksklusibo itong gumagamit ng mga system call, pinili namin ang regular na bash bilang wika ng script, at nag-deploy kami ng open source na solusyon para ikonekta ang HTTP → bash API goexpose, nakasulat sa Go.

Sa ibang araw, ilalabas namin ang aming mga script ng bash sa open source, ngunit sa ngayon ay ilalarawan ko lang ang pangunahing algorithm:

Paglikha ng pangunahing snapshot snapmain:

Paghinto sa pangunahing replika.
Bina-block namin ang mga operasyon gamit ang snapmain snapshot.
Gumawa ng bagong snapshot snapmain.
Ilunsad ang MySQL at alisin ang lock.

Paglikha ng isang database sa isang arbitrary na port mula sa snapmain:

Naglalagay kami ng lock sa isang partikular na halimbawa ng database (port).
Sinusuri namin kung ang paglikha ng pangunahing snapshot ay naharang. Kung ito ay naroroon, pagkatapos ay maghintay kami at muling suriin bawat 5 segundo.
Tinitingnan namin kung may lumang LV section ng instance.
3.1 Kung mayroon, pagkatapos ay gamitin ang kill -9 upang ihinto ang MySQL instance at tanggalin ang LV partition.
Lumilikha kami ng bagong instance mula sa snapmain.
Naghahanda kami at nag-mount ng mga direktoryo para sa pagkakataong ito.
Inalis namin ang mga katangian ng alipin (mga file) at inilunsad ang MySQL instance.
Gawin natin siyang master.
Tinatanggal namin ang pagharang.

Pag-alis ng database sa isang random na port:

Naglalagay kami ng lock sa isang partikular na halimbawa ng database (port).
Patayin ang MySQL instance gamit ang kill -9.
I-unmount natin ang mga direktoryo.
Tinatanggal namin ang partisyon ng LV at tinanggal ang lock.

Mga halimbawang command para sa pag-clone ng mga partisyon ng isang bagong instance ng database:

lvcreate -n stage_3307 -s vga/snapmain
lvchange -ay -K vga/stage_3307
mount -o noatime,nodiratime,data=writeback /dev/mapper/vga-stage_3307 /mnt/stage_3307

Ngayon sasabihin ko sa iyo ang tungkol sa pangunahing problema na nakatagpo namin kapag gumagamit ng manipis na redundancy. Kami ay natigil sa pagganap ng mga SSD drive. Nangyari ito dahil sa mga feature ng Thin LVM: ito ay karaniwang gumagana sa antas ng device na may mababang antas na mga chunks na may default na laki na 4 MB. Ano ang hitsura nito:

Lumikha ng snapshot mula sa pangunahing seksyon /var/lib/mysql.
Nagsisimula kami ng pagtitiklop para makahabol sa master.
Ang anumang pagbabago sa mga replica na talahanayan ay pinipilit ang mga luma, hindi nabagong mga tipak ng data na maiimbak sa seksyong snapshot.
Ang anumang pagbabago sa isang nakataas na instance ng pagsubok ay nagdudulot ng mga luma, hindi nabagong mga tipak ng data na maiimbak sa isang na-clone na seksyon ng snapshot para sa pagkakataong iyon.
Nakakakuha kami ng load ng 100% I/O operations sa device, isang slowdown ng anumang operations at isang unti-unting lag ng replica.
Sa pagtatapos ng araw ng trabaho, nakakakuha kami ng stand na ilang oras sa likod.

Paano namin ito hinarap upang makakuha ng mas matinong resulta (mga pangunahing punto):

RAID controller:

Ang lahat ng uri ng caching ay hindi pinagana bilang default.
Itakda ang writeback (kapag ang data ay pumasok sa buffer, ang pagsulat ay nakumpleto bago ang aktwal na pag-save sa disk ay ginanap).

File system:

Sa mount point /var/lib/mysql isinulat namin noatime,nodiratime,data=writeback
Na-disable ang ext4 logging gamit ang tune2fs.

MySQL:

Inireseta innodb_flush_method = O_DSYNC (tumaas ang bilis ng pag-record, sa gayon ay binabawasan ang pagiging maaasahan).
Naka-disable ang pag-log, hindi namin kailangan ng mga log.
Inireseta innodb_buffer_pool_size = 4G (mas maliit ang laki ng InnoDB pool, mas mabilis na magsasara ang MySQL kapag huminto, at mas mabilis kaming gagawa ng snapshot).

Ito ay hindi isang kumpletong listahan, lalo na para sa MySQL. Gayunpaman, ang natitirang mga pagbabago ay maliit at kadalasan ay hindi palaging o tumpak na naaangkop. Halimbawa, sa pagtatangkang i-unload ang mga disk, inalis pa namin innodb_parallel_doublewrite_path sa /dev/shm, na sa ilang mga kaso ay nag-save sa amin ng hanggang 5 segundo kapag nagsimula ng isang hindi wastong winakasan na instance.

Bakit natin ihihinto ang MySQL bago kumuha ng snapshot? Pagkatapos ng lahat, maaari naming alisin ito mula sa isang gumaganang replika. Tama iyon, ngunit ang bagong instance ng database sa snapshot na ito ay ituturing na sira bilang default at mangangailangan ng buong pag-scan sa startup. Ang paghinto ng isang kopya ay tiyak na mas mabilis, bagama't ito ay nagtatapos sa pagiging ang pinakamahabang operasyon sa buong proseso.

Bilang resulta, nakatanggap kami ng mas katanggap-tanggap na mga timing at isang ready-to-use stand. Bagama't, tulad ng makikita mula sa pinakamahuhusay na graph ng replication lag ng pangunahing replica, malayo pa rin sa ideal ang sitwasyon:

Kabilang sa iba pang mga pagkukulang, nararapat na tandaan ang praktikal na imposibilidad ng pagsubaybay sa Thin LVM pool: bilang karagdagan sa mga standard na function ng iostat ng system, imposibleng maunawaan, halimbawa, kung aling elemento ng pool ang kasalukuyang gumagawa ng pinakamalaking pagkarga sa file system.

Hiwalay, nararapat na tandaan ang isang malaking disbentaha na nauugnay sa pag-optimize na inilarawan sa itaas: nakatanggap kami ng YOLO stand. Halos isang beses bawat isa o dalawang buwan ay hindi makayanan ng ext4 ang naturang pang-aabuso at nasira nang hindi naaayos, na nangangailangan ng muling pag-format at muling pag-upload ng replica. Ang pagkakaroon ng panalo sa bilis, kami ay walang pag-asa na nasira ang katatagan.

Anong mga sukatan ang dapat mong subaybayan habang gumagamit ng Thin LVM:

Data ng manipis na pool %
Manipis na pool metadata %

Kung ang aming stand ay nakaligtas sa pagkaubusan ng espasyo para sa data (ito ay sapat na upang linisin ang mga disk), kung gayon ang pagkaubusan ng espasyo para sa metadata ay hahantong sa isang kumpletong pagbagsak ng pool at ang pangangailangan na muling itayo ito mula sa simula.

Ang file system sa loob ng pool ay nagiging napakapira-piraso sa paglipas ng panahon. Inirerekomenda kong patakbuhin ang cron command isang beses sa isang araw fstrim -v /var/lib/mysql.

Mga subtotal:

Ang teknolohiya ay madaling ilapat, tulad ng LVM mismo, at hindi nangangailangan ng mga espesyal na kwalipikasyon ng engineer.
Ito ay angkop para sa maliliit at hindi masyadong load na mga database. Ang mas maliit ang database, ang mas kaunting mga chunks ay gumagalaw sa paligid ng file system sa loob ng pool, at mas mababa ang load sa mga disk.
Para sa aming gawain, nagsimula kaming maghanap ng iba pang mga solusyon, na tatalakayin sa susunod na seksyon.

Pangalawang paninindigan, teknolohiya ng ZFS

Dati akong gumagamit ng ZFS file system, pero noon, maayos ang paggana ng ZFS sa katutubong pamilya nito ng Solaris OS. May port para sa FreeBSD na may medyo mahusay na antas ng implementasyon. Mayroon ding hindi pa tapos na port para sa Linux, na iilang tao lamang ang gumagamit. Dahil sa istruktura ng pag-iimbak ng datos na B-tree nito (nga pala, ang InnoDB ng MySQL ay may parehong istruktura ng pag-iimbak), hindi maganda ang naging performance ng ZFS sa mga instalasyon na may napakaraming bilang ng mga file. Ito, kasama ang pangangailangang matutunan ang mga pangunahing kaalaman bago gamitin, ang humantong sa pangmatagalang paggamit ko ng file system na ito. Lumitaw ang Ext4 at xfs at naging pamantayan. Ngunit dahil ang ZFS ay higit pa sa angkop para sa ating mga pangangailangan, at LinuxAng bersyon, batay sa mga review, ay lumago at naging isang ganap na makatwirang produkto (bagaman hindi ganap na sinusuportahan, kaya naman ang pag-install ng sistema sa ZFS mula sa simula ay posible lamang sa tulong ng iba't ibang mga pamamaraan ng voodoo), nagpasya kaming subukan ito.

Para sa mga malinaw na dahilan, pinili ang stand na may katulad na configuration (maliban sa RAID controller). Nag-install kami ng walong 1920 GB SSD drive. Walang pagnanais na magsulat ng aming sariling imahe ng network upang i-upload ang server sa hubad na ZFS, kaya kinagat namin ang 50 GB ng lahat ng mga disk at ginawa ang MD RAID-10 sa mga ito para sa system. Ang natitirang 1950 GB sa bawat disk ay pinagsama sa isang ZFS analogue ng RAID-10:

zpool create zpool mirror /dev/sda2 /dev/sdb2 mirror /dev/sdc2 /dev/sdd2 mirror /dev/sde2 /dev/sdf2 mirror /dev/sdg2 /dev/sdh2

Gumawa kami ng mga seksyon para sa MySQL:

zfs create zpool/mysql
zfs set compression=gzip zpool/mysql
zfs set recordsize=128k zpool/mysql
zfs set atime=off zpool/mysql
zfs create zpool/mysql/data
zfs set recordsize=16k zpool/mysql/data
zfs set primarycache=metadata zpool/mysql/data
zfs set mountpoint=/var/lib/mysql zpool/mysql/data

Pakitandaan na pinagana namin ang native gzip data compression. Marami kaming mapagkukunan ng processor sa server at hindi sila ganap na ginagamit Bilang resulta, ang 3 TB ng aming database ay naging 1,6 TB, at dahil ang mahinang link, tulad ng sa nakaraang kaso, ay ang pinakamataas na pagganap ng disk, mas kaunting data ang mas mahusay, nakakakuha kami ng magandang bonus mula sa ZFS mula pa sa simula! Sa rush hour sa full load, aabutin ng hanggang 4 na core para mapanatiling tumatakbo ang gzip, ngunit hindi namin alintana.

Pagkatapos ay naging mas mabilis ang pagpapatupad. Ang mga setting ng replika ng MySQL ay inilipat mula sa LVM stand bilang isang kopya ng carbon. Kinailangan kong gumugol ng ilang oras sa muling pagsulat ng mga script gamit ang mga utos ng ZFS, ngunit sa pangkalahatan ang mga algorithm ay nanatiling pareho. Isang halimbawa ng paggawa ng snapshot:

zfs set snapdir=visible zpool/mysql/data
zfs create zpool/stage_3307
zfs clone zpool/mysql/data@snapmain zpool/stage_3307/data
zfs set mountpoint=/mnt/stage_3307 zpool/stage_3307/data

Mula sa karagdagang pag-tune: inilipat namin ang mga partisyon ng ZFS na may metadata at l2arc at zil log sa memorya. Para sa aming gawain, tulad ng nangyari sa ibang pagkakataon, ito ay kalabisan, ngunit sa ngayon ay iniwan namin ang pag-optimize na ito kung kinakailangan; Ang isa sa mga negatibong epekto ay pagkatapos na i-reboot ang server, kailangan mong muling likhain ang kaukulang mga lugar ng memorya. Walang data na nawala. Zpool status clipping:

logs
      /dev/shm/zil_slog.img  ONLINE       0     0     0
cache
      /dev/shm/l2arc.img     ONLINE       0     0     0

Sa pagsasaayos na ito, sinimulan naming subukan ang stand at nakakuha ng mahusay na mga resulta: sa dalawang sabay-sabay na pagpapatakbo ng mga instance ng database (at isang aktibong pangunahing replica) sa mga snapshot, nakakuha kami ng 50-60% disk utilization.

Inalis namin ang aming pangunahing problema, tulad ng makikita sa replication lag graph (ihambing sa nakaraang graph sa Thin LVM na seksyon):

Bilang karagdagan at salamat dito, napabilis namin nang husto ang lahat ng operasyon: ang ganap na paggawa ng snapshot na may paghinto at pagsisimula ng replica ay tumatagal ng hanggang 40 segundo, ang pag-deploy ng bagong MySQL instance mula sa isang snapshot ay tumatagal ng hanggang 20 segundo. Na higit pa sa kasiya-siya para sa amin at sa aming mga pagsubok sa code ng programa.

Mga subtotal:

Ang mga resulta ay ganap na nasiyahan sa aming pangangailangan upang makakuha ng isang kopya ng database ng produksyon para sa pagsubok ng code.
Ang teknolohiya ay nangangailangan ng pagpasok: kailangan mong maunawaan kung ano ang ZFS at kung paano ito gagawin.
Hindi namin nasuri ang kasalukuyang katayuan ng ZFS na may malaking bilang (mahigit sa 1 milyon) ng maliliit na file. Ngunit ipinapalagay namin na nagpapatuloy ang problema, kaya hindi ko inirerekomenda ang file system na ito para sa anumang imbakan ng file.

Ano ang susunod?

Wala nang ibang gagawin sa loob ng balangkas ng paninindigan; Marahil sa hinaharap ay magdaragdag kami ng mga pagbubukod ng mga talahanayan na hindi kailangan para sa pagsubok sa pag-setup ng pagtitiklop ng stand na ito ay higit na magpapababa sa laki ng database. Hindi pa namin nasubukan ang BTRFS system at ang pagpapatupad nito ng manipis na redundancy na teknolohiya. Gayunpaman, ang gayong gawain ay hindi na katumbas ng halaga, dahil ang pangunahing layunin ay nakamit. Sa pangkalahatan, siyempre, gusto kong lumayo mula sa diskarte na inilarawan sa itaas - ipatupad ang gumaganang paglilipat ng database sa isang kapaligiran ng pagsubok, lumikha ng isang hiwalay na circuit ng database ng pagsubok, at simulan ang pag-shard sa pangunahing database. Isinasagawa na namin ang karamihan sa mga ito, na tiyak na pag-uusapan natin sa mga susunod na artikulo.

Mga resulta ng

Ang orihinal na problema ay nalutas, kahit na sa isang hindi pangkaraniwang paraan. Inilarawan ng mga intermediate na konklusyon ang mga pakinabang at disadvantage ng bawat isa sa mga teknolohiyang ginamit, kaya't magpasya tayo kung aling teknolohiya ang maaaring gamitin at kailan:

Manipis na LVM - para sa maliliit na database at kapag ayaw mo o walang oras upang matuto ng ZFS.
ZFS - kung mayroon kang karanasan sa pagtatrabaho dito o ng pagkakataong gumugol ng oras sa pag-aaral nito sa anumang sitwasyon.

Sa mas mataas na antas ng pagtatanghal, ang artikulong ito ay hindi lamang paghahambing ng teknolohiya ng dalawang file system. Ang pangunahing ideya na nais kong ihatid at palakasin ay hindi ka dapat matakot na mag-isip sa labas ng kahon sa mga sitwasyong kritikal sa negosyo at kumuha lamang ng mga handa na mga recipe. Noong unang panahon, maaari naming iling ang aming mga ulo bilang isang buo sa teknikal na departamento at sabihin na ang gawain ng paglikha ng tatlong-terabyte na mga kopya ng isang database sa wala pang isang minuto ay imposible, at hindi namin kailangan ng mga peligrosong teknolohiya, gawin natin tama na. Posible ito, ngunit mawawalan kami ng humigit-kumulang anim na buwan hanggang isang taon at maraming biyahe ng customer (ang paglalakbay ang pangunahing tagapagpahiwatig ng aming negosyo) nang walang pagsubok at sa panahon ng pagpapatupad. Sa pamamagitan ng pagkilos sa labas ng kahon, hindi kami nawalan ng maraming oras sa pagpapatupad, nakakuha ng karanasan sa mga bago at nakalimutang lumang teknolohiya, at nagbigay ng pagsubok sa oras na talagang kailangan namin ito. Walang alinlangan, ito ay nagkaroon ng positibong epekto sa lahat ng aming mga tagapagpahiwatig. Ang pagpipilian ay palaging sa iyo, at kami, sa aming bahagi, ay patuloy na magsasalita tungkol sa mga kagiliw-giliw na kasalukuyan at hinaharap na mga tagumpay sa aming blog.

Pinagmulan: www.habr.com