Увядзенне
Прыйшла пара купляць СГД. Якую ўзяць, каго слухаць? Вендар А распавядае пра вендара B, а яшчэ ёсць інтэгратар C, які распавядае зваротнае і раіць вендара D. У такой сітуацыі і ў дасведчанага архітэктара па сістэмах захоўвання галава пайдзе вакол, асабліва са ўсімі новымі вендарамі і моднымі сёння SDS і гіперканвергенцыяй.
Дык як жа ва ўсім гэтым разабрацца і не апынуцца ў дурнях? Мы ( Антон Жбанкоў і Яўген Елізараў) паспрабуем пра гэта расказаць рускай мовай па белым.
Артыкул шмат у чым пераклікаецца, і фактычна з'яўляецца пашырэннем “” у плане выбару сістэм захоўвання дадзеных і агляду тэхналогій сістэм захоўвання. Мы коратка разгледзім агульную тэорыю, але рэкамендуем азнаёміцца і з указаным артыкулам.
навошта
Часта можна назіраць сітуацыю як прыходзіць новы чалавек на форум або ў спецыялізаваны чацік, як напрыклад Storage Discussions і задае пытанне: "вось мне прапануюць два варыянты СХД – ABC SuperStorage S600 і XYZ HyperOcean 666v4, што параіце"?
І пачынаецца меранне ў каго якія асаблівасці рэалізацыі страшных і незразумелых фішак, якія для непадрыхтаванага чалавека і зусім кітайская грамата.
Дык вось, ключавое і самае першае пытанне, якое трэба сабе задаць задоўга да параўноўвання спецыфікацый у камерцыйных прапановах - НАВОШТА? Навошта патрэбна гэтая СГД?
Адказ будзе нечаканым, і вельмі ў стылі Тоні Роббінса - каб захоўваць дадзеныя. Дзякуй, капітан! І тым не менш, часам мы так далёка паглыбляемся ў параўнанне дэталяў, што забываемся навошта ўсё гэта ўвогуле які робіцца.
Дык вось, задача сістэмы захоўвання дадзеных - гэта захоўванне і прадастаўленне доступу да ДАНЫХ з зададзенай прадукцыйнасцю. З дадзеных жа мы і пачнем.
Дадзеныя
Тып дадзеных
Што за дадзеныя мы плануем захоўваць? Вельмі важнае пытанне, якое можа выкрасліць вельмі шмат якія СГД нават з разгляду. Напрыклад, плануецца захоўванне відэазапісаў і фатаграфій. Адразу можна выкрэсліваць сістэмы, разлічаныя пад выпадковы доступ малым блокам, або сістэмы з фірмовымі фішкамі ў кампрэсіі / дэдуплікацыі. Гэта могуць быць проста цудоўныя сістэмы, нічога дрэннага не жадаем сказаць. Але ў дадзеным выпадку іх моцныя бакі ці стануць наадварот слабымі (відэа і фота не кампрэсуюцца) ці проста значна павялічаць кошт сістэмы.
І наадварот, калі мэтавае выкарыстанне нагружаная транзакцыйная СКБД, то цудоўныя струменевыя сістэмы пад мультымедыя, здольныя выдаваць гігабайты ў секунду, будуць дрэнным выбарам.
Аб'ём дадзеных
Колькі звестак мы плануем захоўваць? Колькасць заўсёды перарастае ў якасць, гэта не трэба забываць ніколі, асабліва ў наш час экспанентнага росту аб'ёму дадзеных. Сістэмы петабайтнага класа ўжо не рэдкасць, але чым больш петабайт аб'ёму, тым больш спецыфічнай становіцца сістэма, тым менш будзе даступна звыклай функцыянальнасці сістэм са выпадковым доступам малога і сярэдняга аб'ёму. Банальна таму што адны толькі табліцы статыстыкі доступу па блоках становяцца больш даступнага аб'ёму аператыўнай памяці на кантролерах. Не кажучы ўжо аб кампрэсіі / тырынгу. Выкажам здагадку, мы жадаем пераключыць алгарытм кампрэсіі на больш магутны і пераціснуць 20 петабайт дадзеных. Колькі гэта зойме: паўгода, год?
З іншага боку, навошта гарадзіць агарод, калі захоўваць і апрацоўваць трэба 500 ГБ дадзеных? Усяго 500. Бытавыя SSD (з нізкім DWPD) падобнага аб'ёму каштуюць усяго нічога. Навошта для гэтага будаваць фабрыку Fiber Channel і купляць вонкавую СГД высокага класа коштам у чыгунны мост?
Які працэнт ад агульнага аб'ёму гарачыя дадзеныя? Наколькі нераўнамерная нагрузка па аб'ёме даных? Менавіта тут можа вельмі дапамагчы тэхналогія шматузроўневага захоўвання ці Flash Cache, калі аб'ём гарачых дадзеных мізэрны ў параўнанні з агульным. Або наадварот, пры раўнамернай нагрузцы па ўсім аб'ёме, часта сустракаемай у струменевых сістэмах (відэаназіранне, некаторыя сістэмы аналітыкі) падобныя тэхналогіі не дадуць нічога, і толькі павялічаць кошт / складанасць сістэмы.
ІС
Адваротны бок дадзеных - гэта інфармацыйная сістэма, якая выкарыстоўвае гэтыя дадзеныя. ІС валодае наборам патрабаванняў, якія ўспадкуюць дадзеныя. Падрабязней пра ІС гл у “Дызайне віртуалізаванага ЦАД”.
Патрабаванні па адмоваўстойлівасці / даступнасці
Патрабаванні па адмоваўстойлівасці / даступнасці дадзеных ўспадкоўваюцца ад выкарыстоўваючай іх ІС і выяўляюцца ў трох ліках - РПО, OTR, даступнасць.
даступнасць - Доля за зададзены прамежак часу, на працягу якога дадзеныя даступныя для працы з імі. Выяўляецца звычайна ў колькасці 9. Напрыклад, дзве дзявяткі ў год азначае, што даступнасць роўная 99%, ці інакш дапушчаецца 95 гадзін недаступнасці ў год. Тры дзявяткі - 9,5 гадзін у год.
RPO / RTO - гэта паказчыкі не сумарныя, а на кожны інцыдэнт (аварыю), у адрозненне ад даступнасці.
РПО - аб'ём страчаных пры аварыі дадзеных (у гадзінах). Напрыклад, калі адбываецца рэзервовае капіраванне раз суткі, то RPO = 24 гадзіны. Г.зн. Пры аварыі і поўнай страце СГД могуць быць страчаныя дадзеныя аб'ёмам да 24 гадзін (з моманту рэзервовай копіі). Зыходзячы з зададзенага для ІС RPO, напрыклад, пішацца рэгламент рэзервовага капіявання. Таксама, зыходзячы з RPO, можна зразумець наколькі патрэбна сінхронная / асінхронная рэплікацыя дадзеных.
OTR - Час аднаўлення сэрвісу (доступу да дадзеных) пасля аварыі. Зыходзячы з зададзенага значэння RTO мы можам зразумець ці патрэбен метракластар, ці дастаткова аднанакіраванай рэплікацыі. Ці патрэбна шматкантролерная СХД hi end класа - таксама.
Патрабаванні па прадукцыйнасці
Нягледзячы на тое, што гэта цалкам відавочнае пытанне, з ім то якраз і ўзнікае большасць цяжкасцяў. У залежнасці ад таго, ёсць у вас ужо нейкая інфраструктура ці не і будуць будавацца шляхі збору неабходнай статыстыкі.
У вас ужо ёсць СХД і вы шукайце ёй замену ці жадаеце набыць яшчэ адну для пашырэння. Тут усё проста. Вы разумееце, якія сэрвісы ў вас ужо ёсць і якія вы плануеце ўкараняць у найбліжэйшай перспектыве. Грунтуючыся на бягучых сэрвісах вы маеце магчымасць сабраць статыстыку па прадукцыйнасці. Вызначыцца з бягучай колькасцю IOPS і цяперашніх затрымках - якія гэтыя паказчыкі і ці хапае іх для вашых задач? Зрабіць гэта можна як на самой сістэме захоўвання дадзеных, так і з боку хастоў, якія да яе падключаны.
Прычым глядзець трэба не проста бягучую нагрузку, а за нейкі перыяд (лепш месяц). Паглядзець якія максімальныя пікі ў дзённы час, якую нагрузку стварае рэзервовае капіраванне і г.д. Калі ваша СГД ці ПА да яе не дае вам поўны набор гэтых дадзеных, можна скарыстацца бясплатным RRDtool, які ўмее працаваць з большасцю найболей папулярных СГД і камутатараў і зможа падаць вам падрабязную статыстыку па прадукцыйнасці. Таксама варта глядзець нагрузку і на хастах, якія працуюць з дадзенай СХД, па пэўных віртуальных машынах ці што канкрэтна ў вас працуе на дадзеным хасце.
Варта асобна адзначыць, што калі затрымкі на томе і датастары, які знаходзіцца на дадзеным томе адрозніваюцца даволі моцна - варта звярнуць увагу на вашу SAN-сетку, высокая верагоднасць, што з ёй ёсць праблемы і перш чым набываць новую сістэму, варта разабрацца з гэтым пытаннем , бо вельмі высокая верагоднасць павелічэння прадукцыйнасці бягучай сістэмы.
Вы будуеце інфраструктуру з нуля, альбо набываеце сістэму пад нейкі новы сэрвіс, аб нагрузках якога вы не ў курсе. Тут ёсць некалькі варыянтаў: пагутарыць з калегамі на профільных рэсурсах, каб паспрабаваць пазнаць і спрагназаваць нагрузку, звярнуцца да інтэгратара, у якога ёсць досвед укаранення падобных сэрвіс і які зможа разлічыць нагрузку за вас. І трэці варыянт (звычайна самы складаны, асабліва калі гэта дакранаецца самапісных ці рэдкіх прыкладанняў) паспрабаваць высветліць патрабаванні да прадукцыйнасці ў распрацоўнікаў сістэмы.
І, увага, самы правільны варыянт з пункту гледжання практычнага прымянення - гэта пілот на бягучым абсталяванні, альбо абсталяванні прадастаўленым для тэсту вендарам / інтэгратарам.
Спецпатрабаванні
Спецпатрабаванні - усё тое, што не падпадае пад патрабаванні аб прадукцыйнасці, адмоваўстойлівасці і функцыянальнасці па непасрэднай апрацоўцы і прадастаўленні дадзеных.
Адным з самых простых спецпатрабаванняў да сістэмы захоўвання дадзеных можна назваць "адчужальныя носьбіты інфармацыі". І адразу становіцца зразумела, што дадзеная сістэма захоўвання дадзеных павінна складацца з істужачную бібліятэку ці проста стрымер, на які скідаецца рэзервовая копія. Пасля чаго спецыяльна навучаны чалавек падпісвае стужку і ганарліва нясе яе ў спецыяльны сейф.
Іншы прыклад спецпатрабавання - абароненае супрацьударнае выкананне.
Дзе
Другім галоўным складнікам у выбары таго ці іншага СГД з'яўляецца інфармацыя аб тым, ДЗЕ будзе стаяць гэтая СГД. Пачынаючы ад геаграфіі ці кліматычных умоў, і заканчваючы персаналам.
Заказчык
Для каго плануецца дадзеная СГД? Пытанне мае пад сабой наступныя падставы:
Дзяржзаказчык / камерцыйны.
Камерцыйны заказчык не мае ніякіх абмежаванняў, і не абавязаны нават тэндэры праводзіць, акрамя як па ўласных унутраных рэгламентах.
Дзяржзаказчык - справа іншае. 44 ФЗ і іншыя любаты з тэндэрамі і ТЗ, якія могуць быць аспрэчаны.
Заказчык пад санкцыямі
Ну тут пытанне вельмі простае - выбар абмяжоўваецца толькі даступнымі для дадзенага заказчыка прапановамі.
Унутраныя рэгламенты / дазволеныя да закупкі вендары / мадэлі
Пытанне таксама вельмі простае, але пра яго трэба памятаць.
Дзе фізічна
У дадзенай частцы мы разглядаем усе пытанні з геаграфіяй, каналамі сувязі, і мікракліматам у памяшканні размяшчэння.
персанал
Хто будзе працаваць з дадзенай СГД? Гэта не менш важна, чым тое, што СГД непасрэдна ўмее.
Наколькі б не была перспектыўная, крутая і выдатная СХД ад вендара А, сэнсу ставіць яе напэўна няшмат, калі персанал умее працаваць толькі з вендарам B, і далейшых закупак і пастаяннага супрацоўніцтва з А не плануецца.
І зразумела, зваротны бок пытання – наколькі даступны ў дадзенай геаграфічнай лакацыі падрыхтаваны персанал непасрэдна ў кампаніі і патэнцыйна на рынку працы. Для рэгіёнаў можа мець значны сэнс выбар СХД з простымі інтэрфейсамі ці магчымасцю выдаленага цэнтралізаванага кіравання. Інакш у нейкі момант можа стаць пакутліва балюча. Інтэрнэт поўны гісторый як новы супрацоўнік, учарашні студэнт, які прыйшоў, наканфігураваў такога, што ўся кантора палегла.
атачэнне
Ну і зразумела немалаважнае пытанне - у якім асяроддзі будзе працаваць дадзеная СГД.
- Што з электрасілкаваннем / астуджэннем?
- Якое падлучэнне
- Куды яна будзе змантаваная
- І г.д.
Часцяком дадзеныя пытанні лічацца самі сабой якія разумеюцца і асоба не разглядаюцца, але часам менавіта яны могуць перавярнуць усё з дакладнасцю да наадварот.
Што будзе
Вендар
На сёння (сярэдзіна 2019) расійскі рынак СГД можна падзяліць на ўмоўныя 5 катэгорый:
- Вышэйшы дывізіён – заслужаныя кампаніі з шырокай лінейкай ад самых простых дыскавых паліц да hi-end (HPE, DellEMC, Hitachi, NetApp, IBM / Lenovo)
- Другі дывізіён - кампаніі з абмежаванай лінейкай, нішавыя гульцы, сур'ёзныя вендары SDS або узнімальныя пачаткоўцы (Fujitsu, Datacore, Infinidat, Huawei, Pure і тд)
- Трэці дывізіён - нішавыя рашэнні ў рангу low end, танны SDS, накаленыя падзел на ceph і іншых адкрытых праектах (Infortrend, Starwind і тд)
- SOHO сегмент - малыя і сверхмалые СХД ўзроўню дом / малы офіс (Synology, QNAP і тд)
- Імпартазамешчаныя СХД - сюды ўваходзяць як жалеза першага дывізіёна з пераклеенымі лэйбламі, так і рэдкія прадстаўнікі другога (RAIDIX, дамо ім авансам другі), але ў асноўным гэта трэці дывізіён (Aerodisk, Baum, Depo і тд)
Дзяленне досыць умоўнае, і зусім не азначае, што трэці ці SOHO сегмент дрэнныя і іх нельга выкарыстоўваць. У спецыфічных праектах з выразна вызначаным наборам дадзеных і профілем нагрузкі яны могуць адпрацаваць вельмі добрае, далёка пераўзыходзячы першы дывізіён па суадносінах кошт/якасць. Важна спачатку вызначыцца з задачамі, перспектывамі росту, патрабаванай функцыянальнасцю - і тады Synology будзе служыць вам верай і праўдай, а валасы стануць мяккімі і шаўкавістымі.
Адзін з немалаважных фактараў пры выбары вендара - бягучае асяроддзе. Колькі і якіх СГД у вас ужо ёсць, з якімі СГД умеюць працаваць інжынеры. Ці патрэбен вам яшчэ адзін вендар, яшчэ адна кропка кантакту, ці будзеце вы міграваць паступова ўсю нагрузку з вендара А на вендара B?
Не варта пладзіць сутнасці звыш неабходнага.
iSCSI / FC / File
Па пытанні пратаколаў доступу няма адзінага меркавання сярод інжынераў, а спрэчкі нагадваюць больш тэалагічныя дыскусіі, чым інжынерныя. Але ў цэлым можна адзначыць наступныя пункты:
FCoE хутчэй мёртвы, чым жывы.
FC vs iSCSI. Адна з ключавых пераваг FC у 2019 перад IP СХД, выдзеленая фабрыка пад доступ да дадзеных, нівеліруецца выдзеленай IP сеткай. Глабальных пераваг у FC перад IP сеткамі няма і на IP можна будаваць СХД любога ўзроўню нагрузкі, аж да сістэм для цяжкіх СКБД для АБС буйнога банка. З іншага боку, смерць FC прадракаюць ужо не першы год, але гэтаму ўвесь час што тое замінае. На сёння, напрыклад, некаторыя гульцы на рынку СГД актыўна развіваюць стандарт NVMEoF. Ці падзеліць ён лёс FCoE – пакажа час.
Файлавы доступ таксама не з'яўляецца чымсьці нявартым увагі. NFS/CIFS выдатна паказваюць сябе ў прадуктыўных асяроддзях і пры правільным праектаванні маюць не больш нараканняў, чым блокавыя пратаколы.
Гібрыдныя / All Flash Array
Класічныя СХД бываюць 2 відаў:
- AFA (All Flash Array) - сістэмы, аптымізаваныя для выкарыстання SSD.
- Гібрыдныя - якія дазваляюць выкарыстоўваць як HDD, так і SSD або іх спалучэнне.
Галоўнае іх адрозненне - падтрымліваемых тэхналогіі эфектыўнасці захоўвання і максімальны ўзровень прадукцыйнасці (высокія паказчыкі IOPS і нізкія затрымкі). І тыя і іншыя сістэмы (у большасці сваіх мадэляў, не лічачы low-end сегмент) могуць працаваць як блокавыя прылады, так і файлавыя. Ад узроўня сістэмы залежыць і які падтрымліваецца функцыянал, і ў малодшых мадэляў, ён часцей за ўсё зрэзаны да мінімальнага ўзроўня. На гэта варта зважаць, калі вы вывучаеце характарыстыкі пэўнай мадэлі, а не проста магчымасці ўсёй лінейкі ў цэлым. Гэтак жа, вядома, ад узроўня сістэму залежаць і яе тэхнічныя характарыстыкі, такія як працэсар, аб'ём памяці, кэша, колькасць і тыпы партоў і г.д. З пункту гледжання ж Па кіраванні, AFA ад гібрыдных (дыскавых) сістэм адрозніваюцца толькі ў пытаннях рэалізацыі механізмаў працы з SSD назапашвальнікамі, і нават калі вы выкарыстоўваеце SSD у гібрыднай сістэме, гэта зусім не значыць, што вы зможаце атрымаць узровень прадукцыйнасці на ўзроўні AFA сістэмы . Гэтак жа ў большасці выпадкаў inline механізмы эфектыўнага захоўвання на гібрыдных сістэмах адключаны, а іх уключэнне вядзе да страты ў прадукцыйнасці.
Спецыяльныя СГД
Апроч СГД агульнага прызначэння, арыентаваных першым чынам на аператыўную апрацоўку дадзеных, існуюць адмысловыя СХД з ключавымі прынцыпамі, у корані адрознымі ад звыклых (нізкая затрымка, шмат IOPS):
Медыя.
Дадзеныя сістэмы прызначаны пад захоўванне і апрацоўку медыя-файлаў, якія адрозніваюцца вялікім памерам. Соотв. затрымка становіцца практычна няважнай, а на першы план выходзіць здольнасць аддаваць і прымаць дадзеныя шырокай паласой у шмат раўналежных струменяў.
Дэдупліцыруючыя СГД для рэзервовых копій.
Паколькі рэзервовыя копіі адрозніваюцца рэдкай у звычайных умовах падобнасцю аднаго на аднаго (сярэдняя рэзервовая копія адрозніваецца ад учорашняй на 1-2%), дадзены клас сістэм вельмі эфектыўна пакуе запісаныя на іх дадзеныя ў рамках дастаткова невялікай колькасці фізічных носьбітаў. Напрыклад, у асобных выпадках каэфіцыенты кампрэсіі дадзеных могуць дасягаць 200 да 1.
Аб'ектныя СХД.
У гэтых СХД няма звыклых тамоў з блокавым доступам і файлавых шар, а больш за ўсё яны нагадваюць вялізную базу дадзеных. Доступ да аб'екта, які захоўваецца ў падобнай сістэме, ажыццяўляецца па ўнікальным ідэнтыфікатару, або па метададзеным (напрыклад усе аб'екты фармату JPEG, з датай стварэння паміж XX-XX-XXXX і YY-YY-YYYY).
Compliance сістэмы.
Не так часта сустракаюцца ў Расіі на сёння, але згадаць пра іх варта. Прызначэнне такіх СХД - гарантаванае захоўванне дадзеных для адпаведнасці палітыкам бяспекі або патрабаванням рэгулятараў. У некаторых сістэмах (напрыклад EMC Centera) была рэалізаваная функцыя забароны на выдаленне дадзеных - як толькі ключ павернуты і сістэма перайшла ў дадзены рэжым, ні адміністратар, ні хто або іншы фізічна не могуць выдаліць ужо запісаныя дадзеныя.
фірмовыя тэхналогіі
Flash cache
Flash Cache - агульная назва для ўсіх фірмовых тэхналогій выкарыстання флэш-памяці ў якасці кэша другога ўзроўню. Пры выкарыстанні флэш кэша СХД як правіла разлічваецца для забеспячэння з магнітных дыскаў якая ўсталявалася нагрузкі, у той час як пікавую абслугоўвае кэш.
Пры гэтым неабходна разумець профіль нагрузкі і ступень лакалізацыі зваротаў да блокаў тамоў захоўвання. Флэш кэш - тэхналогія для нагрузак з высокай лакалізацыяй запытаў, і практычна непрымяняльная для раўнамерна нагружаных тамоў (як напрыклад для сістэм аналітыкі).
На рынку даступныя дзве рэалізацыі флэш кэша:
- Read Only. У гэтым выпадку кэшуюцца толькі дадзеныя на чытанне, а запіс праходзіць адразу на кружэлкі. Некаторыя вытворцы, як напрыклад, NetApp, лічаць што запіс на іх СХД праходзіць і так аптымальнай выявай, і кэш ніяк не дапаможа.
- Read/Write. Кэшуецца не толькі чытанне, але і запіс, што дазваляе буферызаваць струмень і зменшыць уплыў RAID Penalty, а як следства падвысіць агульную прадукцыйнасць для СХД з не такім аптымальным механізмам запісу.
Яруснасць
Шматузроўневае захоўванне (тырынг) - тэхналогія аб'яднання ў адзіны дыскавы пул узроўняў з рознай прадукцыйнасцю, як напрыклад SSD і HDD. У выпадку ярка выяўленай нераўнамернасці зваротаў да блокаў дадзеных сістэма зможа аўтаматычна адбалансаваць блокі дадзеных, перамясціўшы нагружаныя на высокапрадукцыйны ўзровень, а лядоўні, наадварот, на павальнейшы.
Гібрыдныя сістэмы ніжняга і сярэдняга класаў выкарыстоўваюць шматузроўневае захоўванне з перасоўваннем дадзеных паміж узроўнямі па раскладзе. Пры гэтым памер блока шматузроўневага захоўвання ў лепшых мадэляў складае 256 МБ. Дадзеныя асаблівасці не дазваляюць лічыць тэхналогію шматузроўневага захоўвання тэхналогіяй падвышэння прадукцыйнасці, як памылкова лічыцца шматлікімі. Шматузроўневае захоўванне ў сістэмах ніжняга і сярэдняга класаў - гэта тэхналогія аптымізацыі кошту захоўвання для сістэм з выяўленай нераўнамернасцю нагрузкі.
Snapshot
Колькі мы б не казалі аб надзейнасці СГД, існуе мноства магчымасцяў страціць дадзеныя, якія не залежаць ад апаратных праблем. Гэта могуць быць як вірусы, хакеры ці любое іншае, ненаўмыснае выдаленне/псаванне дадзеных. Па гэтай прычыне, рэзервовае капіраванне прадуктыўных дадзеных з'яўляецца неад'емнай часткай працы інжынера.
Снапшот - гэта здымак тома на нейкі момант часу. Пры працы большасці сістэм, такіх як віртуалізацыя, БД і тд. нам неабходна зняць такі здымак, з якога мы будзем капіраваць дадзеныя ў рэзервовую копію, пры гэтым нашы ІС змогуць спакойна працягваць працаваць з гэтым томам. Але варта памятаць - не ўсе снапшоты аднолькава карысныя. У розных вендараў, розныя падыходы да стварэння снапшотаў, звязаныя з іх архітэктурай.
CoW (Copy-On-Write). Пры спробе запісу блока дадзеных яго арыгінальнае змесціва капіюецца ў адмысловую вобласць, пасля чаго запіс праходзіць звычайна. Такім чынам прадухіляецца пашкоджанне дадзеных усярэдзіне снапшота. Натуральна ўсе гэтыя «паразітныя» маніпуляцыі з дадзенымі выклікаюць дадатковую нагрузку на СХД і па гэтай прычыне вендары з падобнай рэалізацыяй не рэкамендуюць выкарыстоўваць больш за дзесятак снапшотаў, а на высоканагружаных тамах не выкарыстоўваць іх наогул.
RoW (Redirect-on-Write). У дадзеным выпадку, арыгінальны том натуральна замарожваецца, а пры спробе запісу блока дадзеных СХД піша дадзеныя ў адмысловую вобласць у вольнай прасторы, змяняючы месцазнаходжанне дадзенага блока ў табліцы метададзеных. Гэта дазваляе паменшыць колькасць аперацый перазапісу, што ў выніку нівелюе падзенне прадукцыйнасці і здымае абмежаванні на снапшоты і іх колькасць.
Снапшоты бываюць таксама двух тыпаў па стаўленні да прыкладанняў:
Application consitent. У момант стварэння снапшота СХД тузае агента ў аперацыйнай сістэме спажыўца, які прымусова скідае дыскавыя кэшы з памяці на дыск і прымушае зрабіць гэта дадатак. У гэтым выпадку пры аднаўленні з снапшота дадзеныя будуць кансістэнтныя.
Crash consistent. У дадзеным выпадку нічога падобнага не адбываецца і снапшот ствараецца як ёсць. У выпадку ўзнаўлення з такога снапшота карціна ідэнтычная як калі б раптам адключылася сілкаванне і магчымая некаторая страта дадзеных, якія завіслі ў кэшах і так і не якія дайшлі да дыска. Такія снапшоты прасцей у рэалізацыі і не выклікаюць прасадкі прадукцыйнасці ў прыкладаннях, але менш надзейныя.
Навошта патрэбныя снапшоты на сістэмах захоўвання дадзеных?
- Безагентнае рэзервовае капіраванне напрамую з СХД
- Стварэнне тэставых асяроддзяў на аснове рэальных дадзеных
- У выпадку з файлавымі СХД можа выкарыстоўвацца для стварэння асяроддзяў VDI праз выкарыстанне снапшотаў СХД замест гіпервізара
- Забеспячэнне нізкіх RPO шляхам стварэння снапшотаў па раскладзе з частатой значна вышэй за частату рэзервовага капіявання
Кланаванне
Кланаванне тома - працуе па аналагічным прынцыпе, што і снапшоты, але служыць не проста для чытання дадзеных, а для паўнавартаснай працы з імі. Мы маем магчымасць атрымаць дакладную копію нашага тома, з усімі дадзенымі на ім, не робячы фізічнай копіі, што дазволіць зэканоміць месца. Звычайна кланаванне тамоў выкарыстоўваецца або ў Test&Dev або калі вы хочаце праверыць працаздольнасць якіх-небудзь абнаўленняў на вашай ІС. Кланаванне дазволіць зрабіць гэта максімальна хутка і эканамічна з пункта гледжання дыскавых рэсурсаў, т.я. запісаны будуць толькі змененыя блокі дадзеных.
Рэплікацыя / часопісаваньне
Рэплікацыя - механізм стварэння копіі дадзеных на іншы фізічнай СХД. Звычайна існуе фірмовая тэхналогія ў кожнага вендара, якая працуе толькі ўсярэдзіне ўласнай лінейкі. Але таксама ёсць і іншыя рашэнні, у тым ліку якія працуюць на ўзроўні гіпервізара, як напрыклад VMware vSphere Replication.
Функцыянальнасць фірмовых тэхналогій і зручнасць іх выкарыстання звычайна моцна пераўзыходзяць універсальныя, але аказваюцца непрымяняльныя, калі напрыклад неабходна рабіць рэпліку з NetApp на HP MSA.
Рэплікацыя дзеліцца на два падвіды:
Сінхронная. У выпадку сінхроннай рэплікацыі аперацыя запісу перасылаецца на другую СХД неадкладна і не пацвярджаецца выкананне датуль, пакуль выдаленая СХД не пацвердзіць. За рахунак гэтага расце затрымка доступу, але затое мы маем дакладную люстраную копію дадзеных. Г.зн. RPO = 0 для выпадку страты асноўнай СГД.
Асінхронная. Аперацыі запісу выконваюцца толькі на галоўнай СХД і пацвярджаюцца неадкладна, раўналежна назапашваючыся ў буферы для пакетнай перадачы на выдаленую СХД. Падобны від рэплікацыі актуальны для менш каштоўных даных, або для каналаў нізкай прапускной здольнасці або якія маюць высокую затрымку (характэрна для адлегласцей звыш 100 км). Адпаведна RPO = частаце пакетнай адпраўкі.
Часцяком разам з рэплікацыяй існуе механізм часопісавання дыскавых аперацый. У гэтым выпадку вылучаецца адмысловая вобласць для часопісавання і захоўваюцца аперацыі запісы вызначанай глыбіні па часе, альбо абмежаваныя аб'ёмам часопіса. Для асобных фірмовых тэхналогій, як напрыклад EMC RecoverPoint, існуе інтэграцыя з сістэмным ПЗ, якія дазваляюць прывязаць пэўныя закладкі на канкрэтны запіс у часопісе. Дзякуючы гэтаму можна адкаціць стан тома (або стварыць клон) не проста на 23 красавіка 11 гадзін 59 секунд 13 мілісекунд, а на момант, які папярэднічаў “DROP ALL TABLES; COMMIT”.
Metro cluster
Метро кластар - тэхналогія, якая дазваляе стварыць двунакіраваную сінхронную рэплікацыю паміж двума СХД такім чынам, што з боку гэтая пара выглядае як адна СХД. Ужываецца для стварэння кластараў з геаграфічна разнесенымі плячамі на метро- адлегласцях (менш за 100 км).
На прыкладзе выкарыстання ў асяроддзі віртуалізацыі метрокластэр дазваляе стварыць датастар з віртуальнымі машынамі, даступны на запіс адразу з двух датацэнтраў. У гэтым выпадку ствараецца кластар на ўзроўні гіпервізораў, які складаецца з хастоў у розных фізічных датацэнтрах, падлучаны да дадзенага датастару. Што дазваляе зрабіць наступнае:
- Поўная аўтаматызацыя працэсу аднаўлення пасля смерці аднаго з датацэнтраў. Без якіх-небудзь дадатковых сродкаў усе ВМ, якія працавалі ў памерлым датацэнтры, будуць аўтаматычна перазапушчаны ў пакінутым. RTO = таймаўт кластара высокай даступнасці (15 секунд для VMware) + час загрузкі аперацыйнай сістэмы і старту сэрвісаў.
- Disaster avoidance ці, па-руску, пазбяганне катастроф. Калі запланаваны працы па электрасілкаванні ў датацэнтры 1, то мы загадзя, да пачатку прац, маем магчымасць міграваць усю важную нагрузку ў датацэнтр 2 нон стоп.
віртуалізацыя
Віртуалізацыя СХД - гэта тэхнічна выкарыстанне тамоў з іншай СХД у якасці дыскаў. СХД-віртуалізатар можа проста пракінуць чужы том да спажыўца як свой, адначасна люстраваўшы яго на яшчэ адну СХД, ці нават стварыць RAID з вонкавых тамоў.
Класічныя прадстаўнікі ў класе віртуалізацыі СГД – гэта EMC VPLEX і IBM SVC. Ну і зразумела СГД з функцыяй віртуалізацыі – NetApp, Hitachi, IBM / Lenovo Storwize.
Нашто можа спатрэбіцца?
- Рэзерваванне на ўзроўні СГД. Ствараецца люстэрка паміж тамамі, прычым адна палова можа быць на HP 3Par, а іншая на NetApp. А віртуалізатар ад EMC.
- Пераезд даных з мінімальным прастоем паміж СХД розных вытворцаў. Выкажам здагадку, што дадзеныя трэба міграваць са старога 3Par, які пайдзе пад спісанне, на новы Dell. У гэтым выпадку спажыўцы адключаюцца ад 3Par, тамы пракідваюцца пад VPLEX і ўжо прэзентуюцца спажыўцам нанова. Паколькі ні біта на томе не змянілася, праца працягваецца. Фонам запускаецца працэс люстравання тома на новы Dell, а па завяршэнні люстэрка разбіваецца і 3Par адключаецца.
- Арганізацыя метракластэраў.
Кампрэсія / дэдуплікацыя
Кампрэсія і дэдуплікаія - гэта тыя тэхналогіі, якія дазваляюць вам эканоміць дыскавую прастору на вашай СХД. Варта адразу згадаць, што далёка не ўсе дадзеныя падлягаюць кампрэсіі і / або дэдуплікацыі ў прынцыпе, пры гэтым некаторыя тыпы дадзеных ціснуцца і дэдуплікуецца лепш, а якія то - наадварот.
Кампрэсія і дэдуплікацыя бываюць 2 відаў:
У радку - сціск і дэдуплікацыя блокаў дадзеных адбываецца да запісу гэтых дадзеных на дыск. Такім чынам сістэма толькі вылічае хэш блока і параўноўвае яго па табліцы з ужо наяўнымі. Па-першае гэта выконваецца хутчэй, чым проста запіс на дыск, па-другое мы не выдаткоўваем лішнюю дыскавую прастору.
пошта - калі гэтыя аперацыя праводзяць ужо на запісаных дадзеных, якія знаходзяцца на дысках. Адпаведна дадзеныя спачатку запісваюцца на дыск, а толькі потым, вылічаецца хэш і адбываецца выдаленне лішніх блокаў і вызваленне дыскавых рэсурсаў.
Варта сказаць, што большасць вендараў выкарыстоўваюць абодва выгляду, што дазваляе аптымізаваць гэтыя працэсы і тым самым павысіць іх эфектыўнасць. У большасці вендараў СХД, ёсць у наяўнасці ўтыліты, якія дазваляюць прааналізаваць вашыя наборы дадзеных. Гэтыя ўтыліты, якія працуюць па той жа логіцы, што рэалізавана і ў СГД, таму ацэначны ўзровень эфектыўнасці будзе супадаць. Таксама не варта забываць, што ў шматлікіх вендараў ёсць праграмы гарантыі эфектыўнасці, якія абяцаюць узровень не ніжэй заяўленага для вызначанага (ці ўсіх) тыпаў дадзеных. І не варта грэбаваць дадзенай праграмай, бо разлічваючы сістэму пад свае задачы, з улікам каэфіцыента эфектыўнасці канкрэтнай сістэмы, вы можаце зэканоміць на аб'ёме. Гэтак жа варта ўлічваць, што гэтыя праграмы разлічаны на AFA сістэмы, але дзякуючы закупцы меншага аб'ёму SSD, чым HDD у класічных сістэмах, гэта дазволіць зменшыць іх кошт, і калі не зраўняцца з коштам дыскавай сістэмы, то даволі моцна да яе наблізіцца.
Мадэль
І вось тут мы прыходзім да правільна зададзенага пытання.
"Вось мне прапануюць два варыянты СХД – ABC SuperStorage S600 і XYZ HyperOcean 666v4, што параіце"
Ператвараецца ў “Вось мне прапануюць два варыянты СГД – ABC SuperStorage S600 і XYZ HyperOcean 666v4, што параіце?
Мэтавая нагрузка змешаныя віртуальныя машыны VMware з контураў прадуктыў / тэст / распрацоўка. Тэст = прадуктыву. 150 ТБ на кожны з пікавай прадукцыйнасцю 80 IOPS 000kb блокам 8% выпадковага доступу 50/80 чытанне-запіс. 20 ТБ на распрацоўку, там 300 IOPS хопіць, 50 выпадковы, 000 запіс.
Прадуктыў меркавана ў метрокластар RPO = 15 хвілін RTO = 1 гадзіну, распрацоўку ў асінхронную рэплікацыю RPO = 3 гадзіны, тэст на адной пляцоўцы.
Будзе 50ТБ СКБД, было б нядрэнна для іх часопісаванне.
У нас усюды серверы Dell, СХД старыя Hitachi, ледзь спраўляюцца, плануем рост 50% нагрузкі па аб'ёме і прадукцыйнасці”.
Як гаворыцца, у правільна сфармуляваным пытанні змяшчаецца 80% адказу.
Дадатковая інфармацыя
З чым варта азнаёміцца дадаткова на думку аўтараў
Кнігі
- Аліфер і Аліфер "Кампутарныя сеткі". Кніга дапаможа сістэматызаваць і магчыма лепш разумець як працуе асяроддзе перадачы даных для IP / Ethernet сістэм захоўвання
- "EMC Information Storage and Management". Выдатная кніга па асновах СГД, чаму, як і навошта.
Форумы і чаты
агульныя рэкамендацыі
Цэны
Цяпер што ж тычыцца коштаў - наогул на СГД цэны калі і трапляюцца, то звычайна гэта List price, ад якой кожны заказчык атрымлівае індывідуальную скідку. Памер зніжкі складаецца з вялікай колькасці параметраў, так што прадказаць, якую канчатковую цану атрымае менавіта ваша кампанія, без запыту да дыстрыбутара проста немагчыма. Але пры гэтым, у апошні час low-end мадэлі сталі з'яўляцца ў звычайных кампутарных крамах, такіх як, напрыклад або . У іх можна адразу набыць цікавую для вас сістэму па фіксаваным кошце, як любыя кампутарныя камплектавалыя.
Але жадаецца адзначыць адразу, што прамое параўнанне па TB/$ не з'яўляецца дакладным. Калі падыходзіць з гэтага пункта гледжання, то найболей танным рашэннем будзе просты JBOD + сервер, што не дасць ні той гнуткасці, ні той надзейнасці, якія забяспечвае паўнавартасная, двухкантролерная СХД. Гэта зусім не значыць, што JBOD гадасць гадосная і поскудзь брыдкая, проста трэба ізноў-ткі вельмі выразна разумець – як і для якіх мэт вы будзеце выкарыстоўваць гэтае рашэнне. Часта можна пачуць, што ў JBOD няма чаму ламацца, тамака ж адзін бэкплэйн. Аднак і бэкплэйны бывае выходзяць са строю. Усё ламаецца рана ці позна.
Разам
Параўноўваць сістэмы паміж сабой трэба не толькі па кошце, ці не толькі па прадукцыйнасці, а па сукупнасці ўсіх паказчыкаў.
Купляйце HDD толькі калі вы ўпэўненыя, што вам патрэбны HDD. Для нізкіх нагрузак і несжимаемых тыпаў дадзеных, у іншым выпадку, варта звярнуць на праграмы гарантыі эфектыўнасці захоўвання на SSD, якія зараз ёсць у большасці вендараў (і яны сапраўды працуюць, нават у Расіі), але тут усё залежыць ад прыкладанняў і дадзеных, якія будуць размяшчацца на дадзенай СХД.
Не турыцеся за таннасцю. Часам пад гэтыя хаваецца мноства непрыемных момантаў, адзін з якіх Яўген Елізараў апісваў у сваіх артыкулах пра . І што, у канчатковым выніку, гэтая таннасць можа выйсці вам жа бокам. Не варта забыцца - «скупы плаціць двойчы».
Крыніца: habr.com