{"id":83100,"date":"2020-05-28T13:42:10","date_gmt":"2020-05-28T11:42:10","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/bekap-hranilishhe-dlya-tysyach-virtualnyh-mashin-svobodnymi-instrumentami"},"modified":"2020-05-28T13:42:10","modified_gmt":"2020-05-28T11:42:10","slug":"bekap-hranilishhe-dlya-tysyach-virtualnyh-mashin-svobodnymi-instrumentami","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/bekap-hranilishhe-dlya-tysyach-virtualnyh-mashin-svobodnymi-instrumentami","title":{"rendered":"Zapasowe magazyny dla tysi\u0119cy wirtualnych maszyn za darmo.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Zapasowe<\/p>\n

<\/p>\n

Cze\u015b\u0107, niedawno natkn\u0105\u0142em si\u0119 na interesuj\u0105ce zadanie skonfigurowania magazynu do tworzenia kopii zapasowych du\u017cej liczby urz\u0105dze\u0144 blokowych.<\/p>\n

<\/p>\n

Co tydzie\u0144 wykonujemy kopie zapasowe wszystkich maszyn wirtualnych w naszej chmurze, dlatego musimy umie\u0107 obs\u0142ugiwa\u0107 tysi\u0105ce kopii zapasowych i robi\u0107 to maksymalnie szybko i efektywnie.<\/p>\n

<\/p>\n

Niestety standardowe konfiguracje RAID5<\/strong>, RAID6<\/strong> w tym przypadku nie b\u0119d\u0105 odpowiednie, poniewa\u017c proces przywracania na tak du\u017cych dyskach jak nasze b\u0119dzie niezmiernie d\u0142ugi i najprawdopodobniej nigdy si\u0119 nie sko\u0144czy.<\/p>\n

<\/p>\n

Rozwa\u017cmy jakie s\u0105 alternatywy:<\/p>\n

<\/p>\n

Erasure Coding<\/a><\/noindex><\/strong> \u2014 odpowiednik RAID5, RAID6, ale z konfigurowalnym poziomem parzysto\u015bci. W tym przypadku replikacja odbywa si\u0119 nie blokowo, a dla ka\u017cdego obiektu z osobna. Najprostszym sposobem na wypr\u00f3bowanie erasure coding jest wdro\u017cenie minio<\/a><\/noindex>.<\/p>\n

<\/p>\n

DRAID<\/a><\/noindex><\/strong> \u2014 to obecnie jeszcze niewydana funkcjonalno\u015b\u0107 ZFS. W przeciwie\u0144stwie do RAIDZ DRAID ma rozproszony blok parzysto\u015bci i przy przywracaniu anga\u017cuje od razu wszystkie dyski w macierzy, dzi\u0119ki czemu lepiej znosi awarie dysk\u00f3w i szybciej si\u0119 odbudowuje po awarii. <\/p>\n

<\/a><\/noindex><\/p>\n

\"Zapasowe<\/p>\n

<\/p>\n

\"Zapasowe<\/p>\n

Dysponujemy serwerem Fujitsu Primergy RX300 S7<\/strong> z procesorem Intel Xeon CPU E5-2650L 0 @ 1.80GHz<\/strong>, dziewi\u0119cioma modu\u0142ami pami\u0119ci RAM Samsung DDR3-1333 8Gb PC3L-10600R ECC Registered (M393B1K70DH0-YH9)<\/strong>, macierz\u0105 dyskow\u0105 Supermicro SuperChassis 847E26-RJBOD1<\/strong>, pod\u0142\u0105czon\u0105 przez Dual LSI SAS2X36 Expander<\/strong> i 45 dysk\u00f3w Seagage ST6000NM0115-1YZ110<\/strong> w 6TB<\/strong> ka\u017cdy.<\/p>\n

<\/p>\n

Zanim podejmiemy decyzj\u0119, musimy najpierw wszystko odpowiednio przetestowa\u0107.<\/p>\n

<\/p>\n

W tym celu przygotowa\u0142em si\u0119 i przeprowadzi\u0142em testy r\u00f3\u017cnych konfiguracji. U\u017cy\u0142em minio, kt\u00f3re dzia\u0142a\u0142o jako backend S3 i uruchomi\u0142em je w r\u00f3\u017cnych trybach z r\u00f3\u017cn\u0105 liczb\u0105 cel\u00f3w.<\/p>\n

<\/p>\n

G\u0142\u00f3wnie testowano przypadek minio w erasure coding vs software raid z tak\u0105 sam\u0105 liczb\u0105 dysk\u00f3w i dysk\u00f3w parzysto\u015bci, a wi\u0119c: RAID6, RAIDZ2 i DRAID2.<\/p>\n

<\/p>\n

Dla przypomnienia: gdy uruchamiasz minio z jednym celem, to minio dzia\u0142a w trybie bramki S3, udost\u0119pniaj\u0105c Tw\u00f3j lokalny system plik\u00f3w jako magazyn S3. Natomiast gdy uruchomisz minio z wieloma celami, automatycznie w\u0142\u0105czy si\u0119 tryb Erasure Coding, kt\u00f3ry rozprzestrzenia dane pomi\u0119dzy Twoimi celami, zapewniaj\u0105c odporno\u015b\u0107 na awarie.<\/p>\n

Domy\u015blnie minio dzieli cele na grupy po 16 dysk\u00f3w, gdzie na ka\u017cd\u0105 grup\u0119 przypada po 2 pary. Oznacza to, \u017ce jednocze\u015bnie mog\u0105 awarii ulec dwa dyski bez utraty danych.<\/p><\/blockquote>\n

Do testowania wydajno\u015bci u\u017cy\u0142em 16 dysk\u00f3w po 6 TB ka\u017cdy i pisa\u0142em na nich ma\u0142e obiekty o rozmiarze 1 MB, co najdok\u0142adniej odzwierciedla\u0142o nasze przysz\u0142e obci\u0105\u017cenie, poniewa\u017c wszystkie nowoczesne narz\u0119dzia do tworzenia kopii zapasowych dziel\u0105 dane na bloki o kilku megabajtach i zapisuj\u0105 je w ten spos\u00f3b.<\/p>\n

<\/p>\n

Do przeprowadzenia benchmarku u\u017cyto narz\u0119dzia s3bench uruchamianego na zdalnym serwerze, kt\u00f3re wysy\u0142a\u0142o do minio dziesi\u0105tki tysi\u0119cy takich obiekt\u00f3w r\u00f3wnocze\u015bnie w setkach w\u0105tk\u00f3w. Nast\u0119pnie w ten sam spos\u00f3b pr\u00f3bowa\u0142o je za\u017c\u0105da\u0107 z powrotem.<\/p>\n

<\/p>\n

Wyniki benchmarku przedstawione s\u0105 w tabeli poni\u017cej:<\/p>\n

<\/p>\n

\"Zapasowe<\/p>\n

<\/p>\n

Jak widzimy, minio w trybie w\u0142asnego erasure coding dzia\u0142a znacznie gorzej podczas zapisu ni\u017c minio uruchomiony na programowym RAID6, RAIDZ2 i DRAID2 w tej samej konfiguracji.<\/p>\n

<\/p>\n

Osobno poproszono mnie o przetestowanie<\/a><\/noindex> minio na ext4 vs XFS. Co ciekawe, dla mojego typu obci\u0105\u017cenia XFS okaza\u0142 si\u0119 znacznie wolniejszy ni\u017c ext4.<\/p>\n

<\/p>\n

W pierwszej cz\u0119\u015bci test\u00f3w Mdadm wykaza\u0142 przewag\u0119 nad ZFS, ale p\u00f3\u017aniej gmelikov<\/a><\/noindex> zasugerowa\u0142<\/a><\/noindex>, \u017ce mo\u017cna poprawi\u0107 wydajno\u015b\u0107 ZFS, ustawiaj\u0105c nast\u0119puj\u0105ce opcje:<\/p>\n

<\/p>\n

xattr=sa atime=off recordsize=1M<\/code><\/pre>\n
<\/p>\n
i po tym testy z ZFS sta\u0142y si\u0119 znacznie lepsze.<\/p>\n
<\/p>\n
Mo\u017cna r\u00f3wnie\u017c zauwa\u017cy\u0107, \u017ce DRAID nie daje szczeg\u00f3lnej przewagi w wydajno\u015bci nad RAIDZ, ale teoretycznie powinien by\u0107 znacznie bezpieczniejszy.<\/p>\n
<\/p>\n
W dw\u00f3ch ostatnich testach pr\u00f3bowa\u0142em r\u00f3wnie\u017c przenie\u015b\u0107 metadane (special) i ZIL (log) na lustrzane z SSD. Jednak przeniesienie metadanych nie przynios\u0142o du\u017cych korzy\u015bci w szybko\u015bci zapisu, a przy przenoszeniu ZIL moje SSDSC2KI128G8<\/a><\/noindex> osi\u0105gn\u0119\u0142y sufit z 100% utylizacj\u0105, wi\u0119c uwa\u017cam ten test za nieudany. Nie wykluczam, \u017ce gdybym mia\u0142 szybsze dyski SSD, to mog\u0142oby to znacz\u0105co poprawi\u0107 moje wyniki, ale niestety ich nie mia\u0142em.<\/p>\n
<\/p>\n
Ostatecznie zdecydowa\u0142em si\u0119 na u\u017cycie DRAID i mimo swojego statusu beta, jest to najszybsze i najefektywniejsze rozwi\u0105zanie do przechowywania w naszym przypadku.<\/p>\n
<\/p>\n
Stworzy\u0142em prosty DRAID2 w konfiguracji z trzema grupami i dwoma cz\u0119\u015bciami rozproszonymi:<\/p>\n
<\/p>\n
# zpool status data\n  pool: data\n state: ONLINE\n  scan: none requested\nconfig:\n\n    NAME                 STATE     READ WRITE CKSUM\n    data                 ONLINE       0     0     0\n      draid2:3g:2s-0     ONLINE       0     0     0\n        sdy              ONLINE       0     0     0\n        sdam             ONLINE       0     0     0\n        sdf              ONLINE       0     0     0\n        sdau             ONLINE       0     0     0\n        sdab             ONLINE       0     0     0\n        sdo              ONLINE       0     0     0\n        sdw              ONLINE       0     0     0\n        sdak             ONLINE       0     0     0\n        sdd              ONLINE       0     0     0\n        sdas             ONLINE       0     0     0\n        sdm              ONLINE       0     0     0\n        sdu              ONLINE       0     0     0\n        sdai             ONLINE       0     0     0\n        sdaq             ONLINE       0     0     0\n        sdk              ONLINE       0     0     0\n        sds              ONLINE       0     0     0\n        sdag             ONLINE       0     0     0\n        sdi              ONLINE       0     0     0\n        sdq              ONLINE       0     0     0\n        sdae             ONLINE       0     0     0\n        sdz              ONLINE       0     0     0\n        sdan             ONLINE       0     0     0\n        sdg              ONLINE       0     0     0\n        sdac             ONLINE       0     0     0\n        sdx              ONLINE       0     0     0\n        sdal             ONLINE       0     0     0\n        sde              ONLINE       0     0     0\n        sdat             ONLINE       0     0     0\n        sdaa             ONLINE       0     0     0\n        sdn              ONLINE       0     0     0\n        sdv              ONLINE       0     0     0\n        sdaj             ONLINE       0     0     0\n        sdc              ONLINE       0     0     0\n        sdar             ONLINE       0     0     0\n        sdl              ONLINE       0     0     0\n        sdt              ONLINE       0     0     0\n        sdah             ONLINE       0     0     0\n        sdap             ONLINE       0     0     0\n        sdj              ONLINE       0     0     0\n        sdr              ONLINE       0     0     0\n        sdaf             ONLINE       0     0     0\n        sdao             ONLINE       0     0     0\n        sdh              ONLINE       0     0     0\n        sdp              ONLINE       0     0     0\n        sdad             ONLINE       0     0     0\n    spares\n      s0-draid2:3g:2s-0  AVAIL   \n      s1-draid2:3g:2s-0  AVAIL   \n\nerrors: No known data errors<\/code><\/pre>\n
Dobrze, poradzili\u015bmy sobie z przechowywaniem, teraz o tym, czym b\u0119dziemy robi\u0107 kopie zapasowe. Tutaj natychmiast chcia\u0142bym opowiedzie\u0107 o trzech rozwi\u0105zaniach, kt\u00f3re mog\u0142em przetestowa\u0107, a s\u0105 to:<\/p>\n
<\/p>\n
Benji Backup<\/a><\/noindex><\/strong> \u2014 fork Backy2<\/a><\/noindex>, specjalistyczne rozwi\u0105zanie do tworzenia kopii zapasowych urz\u0105dze\u0144 blokowych, ma \u015bcis\u0142\u0105 integracj\u0119 z Ceph. Potrafi pobiera\u0107 r\u00f3\u017cnice mi\u0119dzy migawkami i tworzy\u0107 na ich podstawie kopie zapasowe przyrostowe. Obs\u0142uguje du\u017c\u0105 liczb\u0119 backend\u00f3w przechowywania, w tym zar\u00f3wno lokalne, jak i S3. Wymaga osobnej bazy danych do przechowywania tablicy hase\u0142 deduplikacji. Z wad: napisany w pythonie, ma nieco nieodpowiedzialne CLI.<\/p>\n
<\/p>\n
Borg Backup<\/a><\/noindex><\/strong> \u2014 fork Attic<\/a><\/noindex>, od dawna znane i sprawdzone narz\u0119dzie do tworzenia kopii zapasowych, potrafi tworzy\u0107 kopie danych i dobrze je deduplikowa\u0107. Obs\u0142uguje zapisywanie kopii lokalnie i na zdalnym serwerze za pomoc\u0105 scp. Mo\u017ce tworzy\u0107 kopie zapasowe urz\u0105dze\u0144 blokowych przy uruchomieniu z flag\u0105 --special<\/code>, w\u015br\u00f3d wad: podczas tworzenia kopii zapasowej repozytorium jest ca\u0142kowicie zablokowane, dlatego dla ka\u017cdej wirtualnej maszyny zaleca si\u0119 tworzenie osobnego repozytorium, w zasadzie nie jest to problem, poniewa\u017c ich utworzenie jest bardzo \u0142atwe.<\/p>\n
<\/p>\n
Restic<\/a><\/noindex><\/strong> \u2014 aktywnie rozwijaj\u0105cy si\u0119 projekt, napisany w Go, wystarczaj\u0105co szybki i obs\u0142uguj\u0105cy wiele backend\u00f3w przechowywania, w tym zar\u00f3wno lokalne przechowywanie, jak i scp, S3 i wiele innych. Osobno warto zauwa\u017cy\u0107, \u017ce istnieje specjalnie stworzony rest-server<\/a><\/noindex> dla restic, kt\u00f3ry umo\u017cliwia najszybszy eksport przechowywania do wykorzystania zdalnego. Spo\u015br\u00f3d wszystkich wymienionych, najbardziej mi si\u0119 spodoba\u0142. Umie tworzy\u0107 kopie zapasowe z stdin. Prawie nie ma zauwa\u017calnych wad, ale ma kilka szczeg\u00f3lnych cech:<\/p>\n
<\/p>\n