Першы прататып аб'ектных сховішчаў свет убачыў у 1996 годзе. Праз 10 гадоў Amazon Web Services запусціць Amazon S3, і свет пачне планамерна сыходзіць з розуму ад плоскай адраснай прасторы. Дзякуючы працы з метададзенымі і сваёй магчымасці маштабавацца, не прасядаючы пад нагрузкай, аб'ектныя сховішчы хутка сталі стандартам для большасці сэрвісаў па захоўванні дадзеных у аблоках, і не толькі. Іншая важная асаблівасць - гэта добрая прыстасаванасць для захоўвання архіваў і падобных ім рэдка выкарыстоўваных файлаў. Усе, хто быў звязаны з захоўваннем дадзеных, радаваліся і насілі новую тэхналогію на руках.
Але людская гаворка поўнілася чуткамі, што аб'ектныя сховішчы - гэта толькі пра вялікія аблокі, а калі вам не патрэбныя рашэнні ад праклятых капіталістаў, то зрабіць сваё будзе вельмі складана. Пра разгортванне свайго аблокі ўжо напісана шмат, а вось пра стварэнне так званых S3-compatible рашэнняў інфармацыі замала.
Таму сёння мы разбярэмся, якія ёсць варыянты "Каб як у дарослых, а не CEPH і напільнік пабольш", разгорнем адзін з іх, а правяраць, што ўсё працуе, будзем з дапамогай Veeam Backup & Replication. У ім заяўлена падтрымка працы з S3-сумяшчальнымі сховішчамі, і вось гэтую заяву мы будзем правяраць.
А як у іншых?
Пачаць прапаную з невялікага агляду рынка і варыянтаў аб'ектных сховішчаў. Агульнапрызнаны лідэр і стандарт - гэта Amazon S3. Два бліжэйшых праследавацеля - Microsoft Azure Blob Storage і IBM Cloud Object Storage.
Няўжо і ўсё? Няўжо няма іншых канкурэнтаў? Вядома, канкурэнты ёсць, але нехта ідзе сваім шляхам, як Google Cloud або Oracle Cloud Object Storage, з няпоўнай падтрымкай S3 API. Нехта выкарыстоўвае старыя версіі API, як Baidu Cloud. А некаторыя, накшталт Hitachi Cloud, патрабуюць ужыванні адмысловай логікі, што абавязкова выкліча свае цяжкасці. У любым выпадку, усіх параўноўваюць з Амазонам, які і можна лічыць індустрыяльным стандартам.
А вось у on-premise рашэннях выбар нашмат больш, таму давайце абазначым важныя нам крытэры. У прынцыпе, хопіць усяго двух: падтрымка S3 API і выкарыстанне v4 падпісання. Паклаўшы руку на сэрца, нам як будучаму кліенту цікавыя толькі інтэрфейсы для ўзаемадзеяння, а ўнутраная кухня самага сховішча нас цікавіць ужо не так моцна.
Пад гэтыя простыя ўмовы падыходзіць вельмі шмат рашэнняў. Напрыклад, класічныя карпаратыўныя цяжкавагавікі:
- DellEMC ECS
- NetApp S3 StorageGrid
- Nutanix Buckets
- Pure Storage FlashBlade і StorReduce
- Huawei FusionStorage
Ёсць ніша чыста софтавых рашэнняў, якія працуюць са скрынкі:
- Red Hat Ceph
- SUSE Enterprise Storage
- Cloudian
І нават аматараў старанна апрацаваць напільнікам пасля зборкі не пакрыўдзілі:
- CEPH у чыстым выглядзе
- Minio (Linux версія, бо да Windows версіі ёсць шмат пытанняў)
Спіс далёка не поўны, яго можна абмеркаваць у каментарах. Толькі не забывайце перад укараненнем правяраць апроч API сумяшчальнасці яшчэ і прадукцыйнасць сістэмы. Апошняе, што вам трэба - гэта страта тэрабайтаў дадзеных з-за падвіслых запытаў. Так што не саромейцеся з нагрузачных тэстаў. Наогул увесь дарослы софт, які працуе з вялікімі аб'ёмамі дадзеных, мае як мінімум справаздачы аб сумяшчальнасці. У выпадку з Veeam ёсць па ўзаемным тэсціраванні, якая дазваляе смела заяўляць аб поўнай сумяшчальнасці нашых прадуктаў з канкрэтным абсталяваннем. Гэта ўжо двухбаковая праца, не заўсёды хуткая, але мы ўвесь час пашыраем пратэставаных рашэнняў.
Збіраны наш стэнд
Хочацца крыху пагаварыць аб выбары паддоследнага.
Па-першае, я хацеў знайсці варыянт, які адразу будзе працаваць са скрынкі. Ну ці хаця б з максімальнай верагоднасцю таго, што ён запрацуе без неабходнасці здзяйсняць лішнія рухі цела. Танцы з бубнам і калупанне кансолі ў ночы - гэта вельмі займальна, але часам хочацца, каб працавала адразу. Ды і агульная надзейнасць такіх рашэнняў звычайна вышэй. І так, у нас знік дух авантурызму, мы перасталі лазіць у вокны да каханых жанчын і г.д.(з).
Па-другое, калі ўжо сапраўды, неабходнасць працы з аб'ектнымі сховішчамі ўзнікае ў даволі вялікіх кампаній, так што гэта той самы выпадак, калі глядзець у бок рашэнняў enterprise-ўзроўню не толькі не сорамна, а нават заахвочваецца. Ва ўсякім разе, я пакуль не ведаю прыкладаў, каб кагосьці звольнілі за пакупку падобных рашэнняў.
Зыходзячы з усяго вышэйсказанага, выбар мой упаў на Dell EMC ECS Community Edition. Гэта вельмі цікавы праект, і я лічу неабходным расказаць вам пра яго.
Першае, што прыходзіць у галаву пры выглядзе дадатку. Community Edition - што гэта проста калька з паўнавартаснага ECS з нейкімі абмежаваннямі, якія здымаюцца пакупкай ліцэнзіі. Дык вось не!
Запомніце:
!!!Community Edition - гэта асобны праект, створаны для тэставання, і без тэхпадтрымкі з боку Dell!!
І яго не ператварыць у паўнавартасны ECS, нават калі вельмі захочацца.
Давайце разбірацца
Многія лічаць, што Dell EMC ECS – ці ледзь не самае лепшае рашэнне, калі ў вас узнікла неабходнасць у аб'ектным сховішчы. Усе праекты пад маркай ECS, уключаючы камерцыйныя і карпаратыўныя, ляжаць на . Гэткі жэст добрай волі ад Dell. І апроч софту, які запускаецца на іх брэндавым жалезе, ёсць апенсорс-версія, якую можна разгарнуць хоць у воблаку, хоць на віртуалцы, хоць у кантэйнеры, хоць на любым сваім жалезе. Забягаючы наперад - ёсць нават OVA версія, чым мы і скарыстаемся.
Сам DELL ECS Community Edition – гэта міні-варыянт паўнавартаснага софту, які працуе на брэндавых серверах Dell EMC ECS.
Я вылучыў чатыры галоўныя адрозненні:
- Няма падтрымкі шыфравання. Крыўдна, але не крытычна.
- Адсутнічае Fabric Layer. Гэтая штука адказвае за пабудову кластараў, менеджмент рэсурсаў, абнаўлення, маніторынг і захоўванне Docker вобразаў. Вось тут ужо вельмі крыўдна, але Dell таксама можна зразумець.
- Самае брыдкае следства папярэдняга пункта: памер ноды нельга пашырыць пасля завяршэння ўсталёўкі.
- Няма тэхпадтрымкі. Гэта прадукт для тэставання, які можна выкарыстоўваць у невялікіх інсталяцыях, але заліваць туды петабайты важных дадзеных асабіста я б не вырашыўся. Але тэхнічна перашкодзіць вам гэта зрабіць ніхто ня можа.
А што ў вялікім варыянце?
Галопам па Еўропах прабяжымся па жалезным рашэннямі, каб мець больш поўнае ўяўленне аб экасістэме.
Неяк пацвярджаць або абвяргаць сцвярджэнне, што DELL ECS - гэта лепшае on-prem аб'ектнае сховішча, я не буду, але калі вам ёсць што сказаць на гэтую тэму, з задавальненнем прачытаю ў каментарах. Ва ўсякім разе па версіі Dell EMC упэўнена ўваходзіць у пяцёрку лідэраў OBS рынку. Хоць там не ўлічваюцца cloud-based рашэнні, але гэта асобная размова.
З тэхнічнага пункту гледжання ECS - гэта аб'ектнае сховішча, якое забяспечвае доступ да дадзеных па пратаколах хмарнага захоўвання. Падтрымлівае AWS S3 і OpenStack Swift. Для file-enabled бакетаў ECS падтрымлівае NFSv3 для магчымасці пафайлавага экспарту.
Працэс запісу інфармацыі даволі незвычайны, асабліва пасля класічных сістэм блокавага захоўвання.
- Пры паступленні новых дадзеных ствараецца новы аб'ект, у якога ёсць імя, самі дадзеныя і метададзеныя.
- Аб'екты б'юцца на чанкі па 128 Мб, і кожны чанк запісваецца адразу на тры ноды.
- Адбываецца абнаўленне файла азначніка, дзе запісаныя ідэнтыфікатары і месцы захоўвання.
- Абнаўляецца файл часопіса (лог запісы) і таксама запісваецца на тры ноды.
- Кліенту адпраўляецца паведамленне аб паспяховым запісе
Усе тры копіі дадзеных запісваюцца паралельна. Запіс лічыцца паспяховым, толькі калі ўсе тры копіі былі запісаныя паспяхова.
Чытанне адбываецца прасцей:
- Кліент запытвае дадзеныя.
- У азначніку шукаецца месца захоўвання дадзеных.
- Дадзеныя чытаюцца з адной ноды і адпраўляюцца кліенту.
Саміх сэрвераў даволі шмат, таму паглядзім на самы маленькі Dell EMC ECS EX300. Ён пачынаецца ад 60Тб, маючы магчымасць вырасці да 1,5 Пб. А яго старэйшы брат Dell EMC ECS EX3000 дазваляе ўжо захоўваць ажно 8,6 Пб на стойку.
Дэплой
Тэхнічна Dell ECS CE можна разгарнуць калі заўгодна вялікім. Ва ўсякім разе, абмежаванняў у відавочным выглядзе я не знайшоў. Аднак усё маштабаванне зручна рабіць метадам кланавання самай першай ноды, для якой нам спатрэбяцца:
- 8 віртуальны працэсар
- 64GB RAM
- 16GB для аперацыёнкі
- 1TB непасрэдна для захоўвання
- Апошні рэліз CentOS minimal
Гэта варыянт для выпадку, калі вы жадаеце ўсталёўваць усё самі з самага пачатку. Для нас гэты варыянт не актуальны, т.я. я буду выкарыстоўваць для дэплою OVA вобраз.
Але ў любым выпадку патрабаванні вельмі злыя нават для адной ноды, а калі строга прытрымлівацца літары закона, то такіх нод трэба чатыры.
Аднак распрацоўшчыкі ECS CE жывуць у рэальным свеце, і інсталяцыя праходзіць паспяхова нават з адной надай, а мінімальныя патрабаванні такія:
- 4 віртуальны працэсар
- 16 Гб аператыўнай памяці
- 16 GB для аперацыёнкі
- 104 GB само сховішча
Менавіта такія рэсурсы патрэбныя для разгортвання OVA выявы. Ужо нашмат гуманней і рэалістычней.
Саму ўсталявальную ноду можна ўзяць у афіцыйным . Там жа ёсць падрабязная дакументацыя па дэплоі ўсё-у-адным, але можна яшчэ пачытаць на афіцыйным . Таму падрабязна спыняцца на разгортванні OVA мы не будзем, тамака без фокусаў. Галоўнае - не забудзьцеся перад яе запускам або пашырыць дыск да патрэбнага аб'ёму, або прычапіць неабходныя.
Запускаем машыну, адчыняны кансоль і выкарыстаны самыя лепшыя крэдыты па змаўчанні:
- лагін: admin
- пароль: ChangeMe
Затым запускам sudo nmtui і наладжваем сеткавы інтэрфейс – IP/маска, DNS і гейт. Памятаючы, што ў CentOS minimal няма net-tools, правяраем налады праз ip addr.
І паколькі толькі адважным пакараюцца моры, які робіцца yum update, пасля чаго reboot. Насамрэч гэта даволі бяспечна, т.я. усё разгортванне робіцца праз плэйбукі, а ўсе важныя пакеты докера залачаны на бягучай версіі.
Цяпер надышоў час адрэдагаваць усталявальны скрыпт. Ніякіх вам прыгожых акенцаў ці псеўда UI – усё праз ваш любімы тэкставы рэдактар. Чыста тэхнічна ёсць два шляхі: можна запускаць кожную каманду ручкамі ці адразу запусціць канфігуратар videploy. Ён проста адкрые канфіг у vim, а па выхадзе запусціць яго праверку. Але свядома спрашчаць сабе жыццё не цікава, таму выканаем на дзве каманды больш. Хаця сэнсу ў гэтым ніякага, я вас папярэдзіў =)
Такім чынам, які робіцца vim ECS-CommunityEdition/deploy.xml і ўносім аптымальна-мінімальныя змены, каб ECS улучылася і працавала. Спіс параметраў можна падскароціць, але я зрабіў вось так:
- licensed_accepted: true Можна і не змяняць, тады пры дэплоі вас у відавочным выглядзе папросяць яго прыняць і пакажуць мілую фразу. Магчыма, гэта нават пасхалачка такая.
- Раскаментаваць радкі autonames: і custom: Увесці прынамсі адно жаданае імя для ноды - hostname будзе заменены на яго падчас усталёўкі.
- install_node: 192.168.1.1 пазначыць рэальны IP ноды. У нашым выпадку паказваем той жа, што і ў nmtui
- dns_domain: уводзім свой дамен.
- dns_servers: упісваем свой dns.
- ntp_servers: можна пазначыць любы. Я ўзяў першы які трапіў з пула 0.pool.ntp.org (ім стаў 91.216.168.42)
- autonaming: custom Калі не раскаментаваць, то месяц назавецца Luna.
- ecs_block_devices:
/ DEV / SDB
Па невядомым чынніку тут можа апынуцца неіснуючая прылада блокавага захоўвання. - storage_pools:
Удзельнікі:
192.168.1.1 Тут зноў паказваем рэальны IP ноды - ecs_block_devices:
/dev/sdb Паўтараем аперацыю выразання неіснуючых прылад.
Наогул увесь файл вельмі падрабязна апісаны ў , але хто ж яе чытаць будзе ў такі клапатлівы час. Там жа напісана, што мінімальна-дастатковае – гэта паказаць IP і маску, але ў мяне ў лабе такі набор заводзіўся дрэннавата, і прыйшлося пашырыць да паказанага вышэй.
Пасля выхаду з рэдактара трэба запусціць update_deploy /home/admin/ECS-CommunityEdition/deploy.yml, і калі ўсё зроблена правільна, пра гэта будзе паведамлена ў відавочным выглядзе.
Затым усё ж давядзецца запусціць videploy, дачакацца абнаўлення асяроддзя, і можна запускаць саму ўсталёўку камандай ova-step1, а пасля яе паспяховага выканання каманду ova-step2. Важна: не спыняйце працу скрыптоў рукамі! Некаторыя крокі могуць займаць значны час, выконвацца не з першай спробы і выглядаць так, быццам усё зламалася. У любым выпадку трэба дачакацца завяршэння скрыпту натуральным шляхам. У канцы вы павінны ўбачыць прыкладна такое паведамленне.
Цяпер нарэшце мы можам адкрыць WebUI панэль кіравання па вядомым нам IP. Калі на этапе канфігурацыі не змянялі, то дэфолтная ўлік будзе root/ChangeMe. Можна нават адразу карыстацца нашым S3-сумяшчальным сховішчам. Яно даступна на портах 9020 для HTTP, і 9021 для HTTPS. Ізноў жа, калі нічога не змянялі, то access_key: object_admin1 і secret_key: ChangeMeChangeMeChangeMeChangeMeChangeMe.
Але давайце не будзем забягаць моцна наперад і пачнем па парадку.
Пры першым лагіне вас прымусова папросяць змяніць пароль на адэкватны, што абсалютна правільна. Галоўны дашборд лімітава зразумелы, таму давайце зробім нешта цікавейшае, чым тлумачэнне відавочных метрык. Напрыклад, створым карыстальніка, якога будзем выкарыстоўваць для доступу да сховішча. У свеце сэрвіс-правайдэраў такіх завуць tenant. Робіцца гэта ў Manage > Users > New Object User
Пры стварэнні карыстальніка нас просяць пазначыць namespace. Тэхнічна, нічога нам не мяшае заводзіць іх гэтулькі, колькі будзе карыстачоў. І наадварот. Гэта дазваляе кіраваць рэсурсамі незалежна для кожнага тэнанта.
Адпаведна, выбіраемы неабходныя нам функцыі і генерым ключы карыстача. Мне будзе дастаткова S3/Atmos. І не забываем захаваць ключык 😉
Карыстальніка стварылі, зараз сітавіна яму і бакет вылучыць. Пераходзім у Manage > Bucket і запаўняем патрабаваныя палі. Тут усё проста.
Цяпер у нас усё гатова для суцэль сабе баявога выкарыстання нашага S3 сховішчы.
Наладжваем Veeam
Такім чынам, як мы памятаем, адно з галоўных ужыванняў аб'ектных сховішчаў - гэта доўгачасовае захоўванне інфармацыі, да якой рэдка звяртаюцца. Ідэальным прыкладам служыць неабходнасць захоўвання бекапаў на выдаленай пляцоўцы. У Veeam Backup & Replication гэтая функцыя называецца Capacity Tier.
Пачнём наладу з дадання нашага Dell ECS CE ў інтэрфейс Veeam. На ўкладцы Backup Infrastructure запускаем майстар дадання новага рэпазітара і выбіраемы пункт Object Storage.
Выбіраемы тое, дзеля чаго ўсё ладзілася - S3 Compatible.
У які з'явіўся акенцы пішам жаданае імя і пераходзім на крок Account. Тут трэба пазначыць Service point у выглядзе , рэгіён можна пакінуць як ёсць, і дадаць створанага карыстальніка. Гейт-сервер неабходны, калі ваша сховішча знаходзіцца на выдаленай пляцоўцы, але гэта ўжо тэма аптымізацыі інфраструктуры і асобнага артыкула, так што тут можна смела прапусціць.
Калі ўсё пазначана і настроена правільна, вылезе папярэджанне аб сертыфікаце і затым акно з бакетам, дзе можна стварыць тэчку для нашых файлаў.
Праходзім Візард да канца і атрымліваем асалоду ад вынікам.
На наступным кроку трэба або стварыць новы Scale-out Backup Repository, або дадаць наш S3 у існуючы - ён будзе выкарыстаны ў якасці Capacity Tier для архіўнага захоўвання. Функцыі выкарыстоўваць S3-сумяшчальныя сховішчы напроста, як звычайны рэпазітар, у бягучым рэлізе няма. Занадта шмат даволі невідавочных праблем для гэтага трэба вырашыць, але ўсё можа быць.
Заходзім у налады рэпазітара і ўключаем Capacity Tier. Там усё празрыста, але ёсць цікавы нюанс: калі жадаецца, каб усе дадзеныя ў найкароткія тэрміны адпраўляліся на аб'ектнае сховішча, проста ўсталюеце 0 дзён.
Пасля праходжання візарда, калі не жадаецца чакаць, можна націснуць ctrl+ПКМ на рэпазітары, прымусова запусціць Tiering job і назіраць, як папаўзуць графікі.
На гэтым пакуль усё. Лічу, з задачай паказаць, што блокавыя сховішчы - гэта не так страшна, як прынята думаць, я зладзіўся. Так, рашэнняў і варыянтаў выканання вагон і маленькая каляска, але за адзін артыкул усяго не ахапіць. Таму давайце дзяліцца досведам у каментарах.
Крыніца: habr.com