Въведение
Дойде времето да купите СХД. Какво да изберете, на кого да се доверите? Вендор А разказва за вендора Б, а има и интегратор C, който предлага противоположно и съветва за вендора D. В такава ситуация дори опитен архитект по системи за съхранение може да се обърка, особено с всички нови вендори и модни днес SDS и хиперконвергенцията.
И така, как да се ориентираме и да не се окажем в глупаво положение? Ние ( Антон Жбанков и Евгений Елизаров) ще се опитаме да разкажем за това на руски по прост начин.
Статията в много отношения преплита темите и всъщност е разширение на “” по отношение на избора на системи за съхранение на данни и преглед на технологиите за съхранение. Ние накратко ще разгледаме общата теория, но препоръчваме също да се запознаете с посочената статия.
Защо
Често може да се наблюдава ситуация, в която нов човек влиза във форум или специализиран чат, като например Storage Discussions, и задава въпрос: “Предлагат ми два варианта СХД — ABC SuperStorage S600 и XYZ HyperOcean 666v4, какво бихте ме посъветвали”?
И започва меренето на особени реализирания и странни непознати функции, които за неподготвения човек изглежда като китайска грамота.
Така че, ключовият и първият въпрос, който трябва да си зададете дълго преди да сравнявате спецификациите в търговските предложения — ЗАЩО? Защо е нужна тази СХД?
Отговорът ще бъде неочакван и много в стила на Тони Роббинс — за да съхранявате данни. Благодаря, капитане! И все пак, понякога ние толкова дълбоко се задълбочаваме в сравняването на детайли, че забравяме защо изобщо го правим.
И така, задачата на системата за съхранение на данни — е да съхранява и предоставя достъп до ДАННИ с определена производителност. С данните и започваме.
Данни
Тип данни
Какви данни планираме да съхраняваме? Много важен въпрос, който може да изключи много СХД от разглеждане. Например, планира се съхранение на видеозаписи и снимки. Веднага можем да изключим системите, проектирани за произволен достъп с малки блокове, или системите с фирмени функции за компресия / дедупликация. Това могат да бъдат просто отлични системи, не искаме да кажем нещо лошо. Но в този случай техните силни страни ще станат слаби (видеото и снимките не могат да се компресират) или просто ще увеличат значително цената на системата.
И обратно, ако целевото използване е натоварена транзакционна СУБД, отличните потокови системи за мултимедия, способни да предават гигабайти в секунда, ще бъдат лош избор.
Обем на данните
Колко данни планираме да съхраняваме? Количеството винаги прераства в качество, това не трябва да се забравя никога, особено в наши дни на експоненциален растеж на обема на данните. Петабайтните системи вече не са рядкост, но колкото повече е обемът от петабайти, толкова по-специфична става системата, толкова по-малко ще бъде достъпна познатата функционалност на системите с произволен достъп с малък и среден обем. Просто защото дори само таблиците за статистика на достъпите по блокове стават по-големи от наличния обем оперативна памет на контролерите. Да не говорим вече за компресия / тиринг. Да предположим, искаме да сменим алгоритъма за компресия с по-мощен и да компресираме 20 петабайта данни. Колко време ще отнеме: половин година, година?
От друга страна, защо да правим сложни системи, ако трябва да съхраняваме и обработваме 500 ГБ данни? Само 500. Битовите SSD (с нисък DWPD) на подобен обем струват буквално нищо. Защо да изграждаме фабрика Fiber Channel и да купуваме висококласна външна СХД, струваща като желязен мост?
Какъв процент от общия обем представляват горещите данни? Насколько равномерно е разпределено натоварването по обема данни? Тук може да помогне многостепенната технология за съхранение или Flash Cache, ако обемът на горещите данни е минимален в сравнение с общия. Или обратно, при равномерно натоварване, срещано често в потокови системи (видеонаблюдение, някои аналитични системи), подобни технологии няма да донесат полза, а само ще увеличат разходите / сложността на системата.
ИС
Обратната страна на данните е информационната система, която използва тези данни. ИС притежава набор от изисквания, които данните наследяват. Повече за ИС вижте в „Дизайн на виртуализиран ЦОД“.
Изисквания за устойчивост на откази / наличност
Изискванията за устойчивост на откази / наличност на данните се наследяват от използващата ги ИС и се изразяват в три числа — RPO, RTO, достъпност.
Достъпност — част от зададен интервал време, през който данните са налични за работа. Обикновено се изразява с количества 9. Например, две девятки в годината означават, че наличността е 99%, или по друг начин, допуска се 95 часа недостъпност в годината. Три девятки — 9,5 часа годишно.
RPO / RTO — това са показатели не на сума, а за всеки инцидент (авария), за разлика от наличността.
RPO — обемът на изгубените данни при аварията (в часове). Например, ако резервното копие се прави веднъж на ден, то RPO = 24 часа. Т.е. При авария и пълна загуба на СХД, данните могат да бъдат загубени до 24 часа (от момента на резервната копия). Въз основа на зададения за ИС RPO, например, се пише регламент за резервно копие. Също така, от RPO може да се определи нуждата от синхронна / асинхронна репликация на данните.
RTO — времето за възстановяване на услугата (достъп до данни) след инцидента. Въз основа на зададената стойност RTO можем да разберем дали е необходим метрокластър, или е достатъчна еднопосочна репликация. Нужна ли е многоконтролерна СХД от висок клас — също.
Изисквания за производителност
Въпреки че това е очевиден въпрос, тук възникват повечето трудности. В зависимост от това дали вече имате каквато и да е инфраструктура или не, и ще се изграждат пътища за събиране на необходимата статистика.
Вие вече разполагате с Хранилище за данни и търсите негово заместване или искате да закупите още едно за разширение. Тук всичко е просто. Разбирате какви услуги вече имате и какви планирате да внедрите в близко бъдеще. Въз основа на текущите услуги имате възможност да съберете статистика за производителността. Определете текущото количество IOPS и настоящите закъснения — какви са тези показатели и достатъчни ли са за вашите задачи? Това може да стане както на самата система за съхранение на данни, така и от страна на хостовете, които са свързани с нея.
Важно е да се гледа не само текущото натоварване, а за определен период (по-добре месец). Проверете какви са максималните пикове през дневното време, какво натоварване генерира резервното копиране и т.н. Ако вашето Хранилище за данни или софтуерът за него не ви предоставят пълен набор от тези данни, можете да използвате безплатния RRDtool, който може да работи с повечето популярни Хранилища за данни и комутатори и ще може да ви предостави подробна статистика за производителността. Също така, струва си да се наблюдава натоварването и на хостовете, които работят с това Хранилище за данни, по конкретни виртуални машини или какво конкретно работи на този хост.
Струва си да се отбележи, че ако закъсненията на тома и датастора, който се намира на този том, значително се различават — е добре да обърнете внимание на вашата SAN-мрежа. Има висока вероятност, че с нея има проблеми, и преди да закупите нова система, е добре да разберете този въпрос, тъй като вероятността за увеличение на производителността на текущата система е много висока.
Вие изграждате инфраструктура от нулата или закупувате система за нова услуга, за която не знаете натоварването. Тук има няколко варианта: да се свържете с колеги на специализирани ресурси, за да се опитате да разберете и прогнозирате натоварването, да се обърнете към интегратор, който има опит с внедряване на подобни услуги и който може да изчисли натоварването вместо вас. И третият вариант (обикновено най-трудният, особено ако става въпрос за самостоятелно разработени или редки приложения) е да се опитате да изясните изискванията за производителност от разработчиците на системата.
И, внимание, най-правилният вариант от практическа гледна точка е тест на настоящото оборудване или на оборудването, предоставено за тест от вендора / интегратора.
Специфични изисквания
Специфичните изисквания включват всичко, което не попада под критерии за производителност, отказоустойчивост и функционалност при непосредствената обработка и предоставяне на данни.
Едно от най-простите специфични изисквания за системата за съхранение на данни може да бъде “отчуждаеми носители на информация”. Ясно е, че тази система за съхранение на данни трябва да включва ленточна библиотека или просто стример, на който се съхранява резервна копия. След това специално обучен човек подписва лентата и гордо я носи в специален сейф.
Друг пример за специфично изискване е защитено противоударно изпълнение.
Къде
Вторият основен фактор при избора на съответната СХД е информацията за това КЪДЕ ще бъде поставена тази СХД. Започвайки от географията или климатичните условия и свършвайки с персонала.
Клиент
За кого е планирана тази СХД? Въпросът поставя следните основания:
Държавен клиент / търговски.
Търговският клиент няма ограничения и не е задължен дори да провежда търгове, освен по собствените си вътрешни регламенти.
Държавният клиент е друга работа. 44 ФЗ и онези особености с търговете и спецификациите, които могат да бъдат оспорени.
Клиент под санкции
Тук въпросът е много прост - изборът е ограничен само до наличните предложения за този клиент.
Вътрешни регламенти / разрешени вендори за закупуване / модели
Въпросът също е изключително прост, но е важно да се помни.
Физическо местоположение
В тази част разглеждаме всички въпроси, свързани с географията, комуникационните канали и микроклимата в помещението, където е разположена системата.
Персонал
Кой ще работи с тази СХД? Това е не по-малко важно от самата способност на СХД.
Каквато и да е перспективна, впечатляваща и страхотна СХД от вендор А, няма смисъл да я поставяте, ако персоналът знае само как да работи с вендор Б, а планирането на бъдещи покупки и постоянни отношения с А не е на дневен ред.
И разбира се, обратната страна на въпроса е колко достъпен е подготвеният персонал в конкретната географска локация, както в самата компания, така и на потенциалния пазар на труда. За регионите може да има значителен смисъл изборът на СХД с прости интерфейси или възможност за дистанционно централизирано управление. В противен случай, в някакъв момент може да стане мъчително болезнено. Интернет е пълен с истории как нов служител, вчерашен студент, е конфигурирал нещо такова, че цялата компания да се срути.
Околна среда
И разбира се, не по-малко важен въпрос е в каква среда ще работи тази СХД.
- Как е с електрозахранването / охлаждането?
- Какво е свързването?
- Къде ще бъде монтирана?
- И т.н.
Често тези въпроси се считат за очевидни и не се разглеждат подробно, но понякога точно те могат да обърнат всичко с главата надолу.
Какво?
Доставчик
Към момента (средата на 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 ще ви служи вярно и надеждно, а косата ви ще стане мека и шелковиста.
Един от важните фактори при избора на вендор е текущата среда. Кои и колко хранилища за данни (СХД) вече имате, с какви СХД могат да работят инженерите. Нужен ли ви е още един вендор, още една точка на контакт, ще мигрирате ли постепенно цялото натоварване от вендор A към вендор B?
Не трябва да се създават излишни единици.
iSCSI / FC / File
По въпроса за протоколите за достъп няма единно мнение сред инженерите, а споровете наподобяват повече теологични дискусии, отколкото инженерни. Но като цяло могат да се отбележат следните точки:
FCoE по-скоро мъртъв, отколкото жив.
FC vs iSCSI. Едно от ключовите предимства на FC през 2019 г. пред IP СХД, отделен фабрик за достъп до данни, се нивелира с отделена IP мрежа. Няма глобални предимства на FC пред IP мрежите и на IP могат да се изграждат СХД на всяко ниво на натоварване, включително системи за тежки РСУБД за АБС на голяма банка. От друга страна, смъртта на FC се предсказва вече не за първа година, но постоянно се появяват пречки. В момента, например, някои играчи на пазара на СХД активно развиват стандарта NVMEoF. Ще раздели ли той участта на FCoE — времето ще покаже.
Файлов достъп също не е нещо, което не заслужава внимание. NFS / CIFS показват отлични резултати в продуктивни среди и при правилно проектиране имат не повече оплаквания, отколкото блочните протоколи.
Хибридни / All Flash Array
Класическите СХД са два вида:
- 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).
Системи за съответствие.
Не са толкова чести в Русия днес, но си струва да се споменат. Целта на тези СХД е гарантирано съхранение на данни за спазване на политики за безопасност или изисквания на регулатори. В някои системи (например EMC Centera) е реализирана функция за забрана на изтриване на данни — веднъж щом ключът бъде завъртян и системата премине в този режим, нито администратор, нито кой да е друг физически могат да изтрият вече записаните данни.
Фирмени технологии
Флаш кеш
Флаш кеш – общо наименование за всички фирмени технологии, използващи флаш памет като кеш второ ниво. При използване на флаш кеш СХД обикновено се изчислява, за да осигури натоварването на магнитни дискове, докато пикът се обслужва от кеша.
При това е необходимо да се разбере профилът на натовареност и степента на локализация на обращенията към блоковете на съхранение. Флаш кеш е технология за натоварвания с висока локализация на запитванията и практически не се прилага за равномерно натоварени томове (като например за аналитични системи).
На пазара съществуват две реализации на флаш кеша:
- Read Only. В този случай се кешират само данни за четене, а записът преминава директно на дисковете. Някои производители, например NetApp, считат, че записът на техните СХД минава и така по оптимален начин и кешът не би помогнал.
- Read/Write. Кешира се не само четенето, но и записването, което позволява буфериране на потока и намаляване на влиянието на RAID Penalty, а оттук повишаване на общата производителност за СХД с не толкова оптимален механизъм на запис.
Тиринг
Многостепенно съхранение (тиринг) — технология за обединение на един диск пул от нива с различна производителност, като например SSD и HDD. В случай на ярко изразена неравномерност при достъпа до блокове данни, системата може автоматично да балансира блоковете, премествайки натоварените на по-високо производително ниво, а студените — на по-бавно.
Хибридните системи от нисък и среден клас използват многостепенно съхранение с преместване на данните между нивата по график. Размерът на блока за многостепенно съхранение при най-добрите модели е 256 MB. Тези особености не позволяват технологията за многостепенно съхранение да се счита за технология за увеличаване на производителността, както грешно се смята от много хора. Многостепенното съхранение в системи от нисък и среден клас е технология за оптимизация на разходите за съхранение при системи с ясно изразена неравномерност на натоварването.
Снапшот
Колкото и да говорим за надеждността на СХД, съществуват множество възможности за загуба на данни, независещи от хардуерни проблеми. Те могат да бъдат вируси, хакери или всяко друго, непреднамерено изтриване/повреждане на данни. Поради тази причина, резервното копие на продуктивните данни е неразривна част от работата на инженера.
Снапшотът е моментна снимка на тома в определен момент от времето. При работа с повечето системи, като виртуализация, БД и т.н., е необходимо да направим такава снимка, от която ще копираме данни в резервно копие, като нашите ИС могат спокойно да продължат да работят с този том. Но е важно да помним — не всички снапшоти са еднакво полезни. Различните вендори имат различни подходи към създаването на снапшоти, свързани с тяхната архитектура.
CoW (Copy-On-Write). При опит за запис на блок данни, оригиналното му съдържание се копира в специална зона, след което записът протича нормално. Така се предотвратява повреждането на данните в снапшота. Естествено, всички тези „паразитни“ манипулации с данните предизвикват допълнителна натовареност на СХД и поради тази причина вендорите с подобна реализация не препоръчват използването на повече от десет снапшота, а на високо натоварени томове — изобщо не ги използват.
RoW (Redirect-on-Write). В този случай, оригиналният том, естествено, се замразява, а при опит за запис на блок данни, СХД записва данните в специална област в свободното пространство, променяйки местоположението на този блок в таблицата за метаданни. Това позволява да се намали броят на операциите по презапис, което в крайна сметка нивелира спадовете в производителността и премахва ограниченията за снапшотите и тяхното количество.
Снапшотовете могат да бъдат и два типа по отношение на приложенията:
Application consistent. В момента на създаване на снапшота, СХД извиква агента в операционната система на потребителя, който принудително изхвърля дисковите кешове от паметта на диска и кара приложението да направи това. В този случай, при възстановяване от снапшота, данните ще бъдат консистентни.
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”.
Метро кластер
Метро кластер — технология, позволяваща създаването на двупосочна синхронна репликация между две СХД по такъв начин, че отстрани тази двойка изглежда като едно СХД. Приложима е за създаване на клъстери с географски разнесени разстояния на метро-разстояния (по-малко от 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 вида:
Inline — компресията и дедупликацията на блоковете данни се извършват преди записването им на диска. Така системата първо изчислява хеш на блока и го сравнява с таблицата с вече съществуващите. Първо, това се извършва по-бързо, отколкото просто запис на диск, и второ, не харчим излишно дисково пространство.
Пост — когато тези операции се извършват върху данни, които вече са записани на дисковете. Съответно данните първо се записват на диска, а след това се изчислява хеш и се извършва премахването на излишните блокове и освобождаването на дисковите ресурси.
Трябва да се каже, че повечето доставчици използват и двата типа, което позволява оптимизиране на тези процеси и по този начин увеличава тяхната ефективност. Повечето доставчици на СХД разполагат с инструменти, които позволяват анализ на вашите набори от данни. Тези инструменти работят на същия принцип, който е реализиран и в СХД, поради което оценъчният уровень на ефективност ще съвпадне. Също така, не трябва да забравяме, че много доставчици предлагат гаранционни програми за ефективност, които обещават ниво не по-ниско от заявеното за определени (или всички) типове данни. И не трябва да подценявате тази програма, тъй като проектирайки система за своите нужди, в контекста на коефициента на ефективност на конкретната система, можете да спестите обем. Освен това трябва да се има предвид, че тези програми са проектирани за AFA системи, но благодарение на закупуването на по-малък обем SSD, отколкото HDD в класическите системи, това ще позволи да се намали цената им, и ако не се стигне до цената на дисковата система, то доста да се приближи до нея.
Модел
И тук стигаме до правилно зададения въпрос.
“Предлагат ми две опции за СХД — ABC SuperStorage S600 и XYZ HyperOcean 666v4, какво бихте посъветвали?”
Се превръща в “Предлагат ми две опции за СХД — ABC SuperStorage S600 и XYZ HyperOcean 666v4, какво бихте посъветвали?
Целевата натовареност смесени виртуални машини VMware от продуктивни/тестови/развойни среди. Тест = продукция. 150 ТБ на всеки с пикова производителност 80 000 IOPS с блокове от 8kb, 50% случайен достъп 80/20 четене-запис. 300 ТБ за развитие, там 50 000 IOPS ще е достатъчно, 80 случайна, 80 запис.
Продуктивът предположително в метрокластер 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, които вече предлагат повечето производители (и те наистина работят, дори и в Русия), но всичко зависи от приложенията и данните, които ще се съхраняват на съответната SСД.
Не гоним ниските цени. Понякога зад тях стоят много неприятни моменти, един от които Евгений Елизаров е описал в своите статии за . И в крайна сметка, тази евтиност може да ви излезе скъпо. Не забравяйте — «скъпият плаща два пъти».
Източник: habr.com
