Въведение
Дойде време да купим СХД. Коя да вземем, на кого да се доверим? Вендор А говори за вендор B, а има и интегратор C, който казва обратното и съветва вендор D. В такава ситуация и опитният архитект по системи за съхранение ще се обърка, особено с всички нови вендори и модните в момента SDS и хиперконвергенция.
И така, как да се оправим в цялата тази ситуация и да не се окажем на губещата страна? Ние ( Антон Жбанков и Евгений Елизаров) ще се опитаме да ви разкажем на руски език по бял начин.
Статията в много отношения е свързана и всъщност е разширение на “” по отношение на избора на системи за съхранение на данни и преглед на технологиите за системи за съхранение. Ние накратко ще разгледаме общата теория, но препоръчваме да се запознаете и с указаната статия.
Защо
Често можем да наблюдаваме ситуацията, когато нов човек влиза в форум или в специализиран чат, като например Storage Discussions, и задава въпрос: “предлагат ми два варианта СХД — ABC SuperStorage S600 и XYZ HyperOcean 666v4, какво бихте предложили”?
И започва меренето у кого какви спецификации и странни функции, които за неподготвения човек са изцяло на китайски.
Така че, основният и най-важен въпрос, който трябва да си зададем много преди да сравняваме спецификациите в комерсиалните предложения — ЗАЧЕМ? За какво ни е тази СХД?
Отговорът ще бъде неочакван и много в стила на Тони Роббинс — за да съхраняваме данни. Благодаря, капитан! И все пак, понякога се задълбочаваме толкова в сравняването на подробности, че забравяме защо изобщо правим всичко това.
Така че, задачата на системата за съхранение на данни — е да съхранява и предоставя достъп до ДАННИ при зададена производителност. Именно с данните ще започнем.
Данни
Тип данни
Какви данни планираме да съхраняваме? Много важен въпрос, който може да изключи много системи за съхранение от разглеждане. Например, планира се съхранение на видеозаписи и снимки. Веднага можем да изключим системи, предназначени за случайно достъп nhỏ обем, или системи с фирмени функции за компресиране/дедупликация. Те могат да бъдат просто отлични системи, не искаме да кажем нищо лошо за тях. Но в този случай техните силни страни или ще се окажат слаби (видео и снимки не се компресират) или просто значително ще увеличат цената на системата.
И наоборот, ако целевото използване е натоварена транзакционна СУБД, то отличните потокови системи за мултимедия, способни да предават гигабайти в секунда, ще бъдат лош избор.
Обем на данните
Колко данни планираме да съхраняваме? Количеството винаги преминава в качество, това никога не трябва да се забравя, особено в наше време на експоненциален растеж на обема на данните. Системи от пета байт клас вече не са рядкост, но колкото повече е обемът от пета байт, толкова по-специфична става системата, толкова по-малко ще бъде налична познатата функционалност на системи с малък и среден обем случайно достъп. Дори само таблиците за статистика на достъп по блокове стават по-големи от наличната оперативна памет на контролерите. Да не говорим за компресия/тиринг. Да предположим, че искаме да превключим алгоритъма за компресия на по-мощен и да компресираме 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 можем да разберем дали е необходим метрокластер, или е достатъчна еднопосочна репликация. Нужна ли е многоконтролерна СХД от клас hi end — също.
Изисквания за производителност
Въпреки че това е напълно очевиден въпрос, именно с него възникват повечето трудности. В зависимост от това, имате ли вече някаква инфраструктура или не и как ще се изграждат пътищата за събиране на необходимата статистика.
Вие вече имате СХД и търсите заместител или искате да закупите още една за разширение. Тук всичко е просто. Разбирате какви услуги вече имате и какви планирате да внедрите в близко бъдеще. На базата на текущите услуги имате възможност да съберете статистика за производителността. Определете текущото количество IOPS и настоящите закъснения — какви са тези показатели и достатъчни ли са за вашите задачи? Можете да го направите както на самата система за съхранение на данни, така и от страна на хостовете, които са свързани с нея.
Трябва да се погледне не само текущото натоварване, а и за определен период (по-добре месец). Вижте какви са максималните пикова натоварвания през деня, какво натоварване генерира архивирането и т.н. Ако вашата СХД или софтуерът към нея не ви предоставят целия набор от тези данни, може да се възползвате от безплатния RRDtool, който работи с повечето популярни СХД и комутатори и може да ви предостави подробна статистика за производителността. Също така е добре да се наблюдава натоварването и на хостовете, които работят с тази СХД, по конкретни виртуални машини или какво точно работи на този хост.
Важно е да се отбележи, че ако закъсненията на тома и датастора, който се намира на този том, значително се различават — трябва да обърнете внимание на вашата SAN мрежа, вероятността е висока, че има проблеми с нея и преди да закупите нова система, е разумно да се занимаете с този въпрос, тъй като вероятността за увеличаване на производителността на текущата система е много висока.
Вие изграждате инфраструктура от нулата или купувате система за нова услуга, за натоварването на която не сте запознати. Има няколко варианта: да се консултирате с колеги на специализирани ресурси, за да опитате да разберете и прогнозиране натоварването, да се обърнете към интегратор, който има опит с внедряване на подобни услуги и който може да изчисли натоварването вместо вас. И третият вариант (обикновено най-сложен, особено ако става въпрос за самописани или редки приложения) е да се опитате да разберете изискванията за производителност от разработчиците на системата.
И, внимание, най-подходящият вариант с оглед на практическото приложение е пилот на текущото оборудване или на оборудването, предоставено за тест от вендора / интегратора.
Специални изисквания
Специални изисквания – всичко, което не попада под изискванията за производителност, отказоустойчивост и функционалност относно непосредствената обработка и предоставяне на данни.
Едно от най-простите специални изисквания за система за съхранение на данни може да бъде "изменяеми носители на информация". Незабавно става ясно, че тази система за съхранение на данни трябва да включва лента библиотека или просто стример, на който се записва резервната копия. След това специално обучен човек подписва лентата и гордо я носи в специална каса.
Друг пример за специално изискване – защитено удароустойчиво изпълнение.
Където
Втората основна съставна част при избора на определена СХД е информацията за това, КЪДЕ ще бъде поставена тази СХД. Започвайки от географията или климатичните условия, и завършвайки с персонала.
Поръчител
За кого е планирана тази СХД? Въпросът има следните основания:
Държавен поръчител / търговски.
Търговският поръчител няма никакви ограничения и дори не е задължен да провежда търгове, освен по собствените си вътрешни регламенти.
Държавният поръчител е различен. 44 ФЗ и другите предимства с търговете и ТЗ, които могат да бъдат оспорвани.
Поръчител под санкции
Тук въпросът е много прост – изборът се ограничава само до наличните предложения за този поръчител.
Вътрешни регламенти / разрешени за поръчка вендори / модели
Въпросът също е крайно прост, но трябва да се помни.
Къде физически
В тази част разглеждаме всички въпроси, свързани с географията, комуникационните канали и микроклимата в помещението, където се намира.
Персонал
Кой ще работи с тази СХД? Това е не по-малко важно, отколкото това, което самата СХД умее.
Без значение колко перспективна, страхотна и забележителна е СХД от вендор А, няма смисъл да се инсталира, ако персоналът знае как да работи само с вендор B и не се планират бъдещи покупки и постоянно сътрудничество с А.
И разбира се, обратната страна на въпроса е колко достъпен е подготвеният персонал в конкретната географска локация, както в компанията, така и на потенциалния трудов пазар. За регионите би било от значение да се избере СХД с прости интерфейси или с възможност за отдалечено централизирано управление. В противен случай, в един момент може да стане изключително болезнено. Интернет е пълен с истории как ново назначен служител, вчерашен студент, е конфигурирал нещо, заради което цялата компания е паднала.
Окръжение
И разбира се, не по-малко важен е въпросът — в каква среда ще работи тази СХД.
- Как е с електрозахранването / охлаждането?
- Какво свързване
- Къде ще бъде монтирана
- и т.н.
Често тези въпроси се считат за очевидни и не се разглеждат подробно, но понякога именно те могат да обърнат всичко с точност до обратното.
Какво
Вендор
Към момента (средата на 2019) руският пазар на СХД може да бъде разделен условно на 5 категории:
- Висш дивизион — утвърдени компании с широка гама от най-простите дискови рафтове до hi-end (HPE, DellEMC, Hitachi, NetApp, IBM / Lenovo)
- Втори дивизион — компании с ограничен асортимент, нишови играчи, сериозни доставчици на SDS или нововъзникващи
- Трети дивизион — нишови решения в категория low end, евтин SDS, пълнежи на базата на ceph и други отворени проекти (Infortrend, Starwind и т.н.)
- Сегмент SOHO — малки и супер малки СХД на ниво дом/малък офис (Synology, QNAP и т.н.)
- СХД с импортозамещение — тук влизат както желязото от първи дивизион с сменени етикети, така и редки представители на втори (RAIDIX, да им дадем аванс на втори), но основно това е трети дивизион (Aerodisk, Baum, Depo и т.н.)
Разделението е достатъчно условно и изобщо не означава, че третият или SOHO сегмент са лоши и не могат да се използват. В специфични проекти с ясно дефиниран набор от данни и профил на натоварване те могат да работят много добре, далеч надминавайки първия дивизион по отношение цена/качество. Важно е първо да се определят задачите, перспективите за растеж и необходимата функционалност — и тогава Synology ще ви служи вярно, а косата ще стане мека и копринена.
Един от важните фактори при избора на вендор е настоящата среда. Колко и какви СХД вече имате, с какви СХД работят вашите инженери. Нужен ли е още един вендор, още една точка за контакт, ще мигрирате ли постепенно цялото натоварване от вендор А на вендор B?
Не следва да се създават излишни единици.
iSCSI / FC / File
По въпросите на достъпните протоколи няма единно мнение сред инженерите, а споровете напомнят повече на теологични дискусии, отколкото на инженерни. Но в общи линии могат да се отбележат следните точки:
FCoE повече мъртъв, отколкото жив.
FC срещу 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) е реализирана функция за забрана на изтриването на данни — веднъж щом ключът бъде завъртян и системата премине в този режим, нито администратор, нито който и да е друг физически могат да изтрият вече записаните данни.
Фирмени технологии
Flash кеш
Flash Cache – общо название за всички фирмени технологии, използващи флаш памет като кеш второ ниво. При използване на флаш кеш, СХД обикновено са проектирани да осигурят натоварването от магнитни дискове, докато пикът се обслужва от кеша.
При това е необходимо да се разбере профилът на натоварването и степента на локализация на обращението към блоковете на томовете за съхранение. Флаш кеш – технология за натоварвания с висока локализация на заявките и практически не се използва за равномерно натоварени томове (както например за аналитични системи).
На пазара са налични две реализации на флаш кеш:
- Read Only. В този случай кешират само данни за четене, а записът преминава веднага на дисковете. Някои производители, като например NetApp, смятат, че записът на техните СХД преминава оптимално и кешът по никакъв начин не помага.
- Read/Write. Кешират се не само данни за четене, но и за запис, което позволява буфериране на потока и намаляване на влиянието на RAID Penalty, а оттам и повишаване на общата производителност за СХД с не чак толкова оптимален механизъм за запис.
Тиринг
Многоуровневото съхранение (тиринг) е технология за обединяване в един дисков пул на нива с различна производителност, като например SSD и HDD. В случай на ясно изразена неравномерност в достъпа до блоковете данни, системата ще може автоматично да балансира блоковете данни, премествайки натоварените на високо производително ниво, а прохладните, обратно, на по-бавен.
Хибридните системи от ниско и средно ниво използват многостепенно съхранение с преместване на данни между нивата по график. При това размерът на блока за многостепенно съхранение при най-добрите модели е 256 MB. Тези особености не позволяват да се счита технологията за многостепенно съхранение за технология, повишаваща производителността, както погрешно смятат мнозина. Многостепенното съхранение в системите от ниско и средно ниво е технология за оптимизация на разходите за съхранение при системи с изразена неравномерност в натоварването.
Снимка
Колкото и да говорим за надеждността на СХД, съществуват много възможности за загуба на данни, независещи от хардуерни проблеми. Такива могат да бъдат вируси, хакери или всяко друго, неволно изтриване/повреждане на данни. Поради тази причина, архивирането на продуктивни данни е неотменна част от работата на инженера.
Снапшотът е снимка на тома в определен момент от времето. При работа с повечето системи, като виртуализация, БД и т.н., е необходимо да направим такава снимка, от която ще копираме данни в резервно копие, като в същото време нашите ИС ще могат да продължат да работят спокойно с този том. Но е важно да се помни — не всички снапшоти са еднакво полезни. Различните производители имат различни подходи за създаване на снапшоти, свързани с тяхната архитектура.
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”.
Метро клъстер
Метро клъстер — технология, която позволява създаването на двустранна синхронна репликация между две хранилища по такъв начин, че отстрани тази двойка да изглежда като едно хранилище. Използва се за създаване на клъстери с географски раздалечени отдалечени точки на метро разстояния (по-малко от 100 км).
На примера на използване в среда на виртуализация, метро клъстер позволява създаването на дата стор с виртуални машини, достъпен за запис веднага от две дата центрове. В този случай се създава клъстер на ниво хипервизори, състоящ се от хостове в различни физически дата центрове, свързани с този дата стор. Това позволява извършването на следното:
- Пълна автоматизация на процеса на възстановяване след смъртта на един от дата центровете. Без никакви допълнителни средства, всички виртуални машини, работещи в починалия дата център, ще бъдат автоматично рестартирани в останалия. RTO = тайм-аут на кластера с висока наличност (15 секунди за VMware) + време за зареждане на операционната система и стартиране на услугите.
- Избягване на бедствия или, на руски, предотвратяване на катастрофи. Ако са планирани работи по захранването в дата център 1, то ние предварително, преди началото на работата, имаме възможност да мигрираме цялото важно натоварване в дата център 2 без прекъсване.
Виртуализация
Виртуализация на СХД — това е технически използването на обеми от друга СХД като дискове. Виртуализаторът на СХД може просто да предостави чужд том на потребителя като свой, едновременно репликирайки го на друга СХД, или дори да създаде RAID от външни томове.
Класическите представители в класа на виртуализацията на СХД са EMC VPLEX и IBM SVC. И, разбира се, СХД с функция за виртуализация — NetApp, Hitachi, IBM / Lenovo Storwize.
Защо може да е необходимо?
- Резервиране на ниво СХД. Създава се огледало между томове, като една половина може да бъде на HP 3Par, а другата на NetApp. А виртуализаторът е от EMC.
- Преместване на данни с минимално прекъсване между СХД на различни производители. Да предположим, че данните трябва да бъдат мигрирани от стария 3Par, който ще излезе от употреба, на новия Dell. В този случай потребителите се откъсват от 3Par, томовете се прокарват под VPLEX и вече се представят на потребителите отново. Тъй като нито един бит на тома не е променен, работата продължава. На заден план се стартира процес на репликация на тома на новия Dell, а след завършването му огледалото се разбива и 3Par се изключва.
- Организиране на метрокластери.
Компресия / дедупликация
Компресията и дедупликацията са технологии, които ви позволяват да спестите дисково пространство на вашата СХД. Важно е веднага да се спомене, че далеч не всички данни подлежат на компресия и/или дедупликация, като при това някои типове данни се компресират и дедуплицират по-добре, а други — обратно.
Компресията и дедупликацията са два вида:
Inline — компресията и дедупликацията на блоковете данни се извършва преди записването на тези данни на диск. По този начин системата само изчислява хаш на блока и го сравнява с таблицата с вече съществуващите. Първо, това се изпълнява по-бързо, отколкото просто запис на диск, и второ, не изразходваме излишно дисково пространство.
Post — когато тези операции се извършват вече на записаните данни, които са на дисковете. Съответно данните първо се записват на диск, а след това се изчислява хаш и се извършва премахването на излишните блокове и освобождаването на дисковите ресурси.
Струва си да се каже, че повечето доставчици използват и двата вида, което позволява оптимизация на тези процеси и по този начин повишава тяхната ефективност. Повечето доставчици на системи за съхранение имат налични утилити, които позволяват анализ на вашите набори данни. Тези утилити работят на същата логика, която е реализирана и в системите за съхранение, така че оценъчният ниво на ефективност ще съвпада. Също така не бива да се забравя, че много доставчици предлагат програми за гаранция на ефективността, които обещават ниво не по-ниско от обявеното за определен (или всички) типове данни. И не бива да се пренебрегва тази програма, тъй като при проектиране на система за вашите нужди, отчитайки коефициента на ефективност на конкретната система, можете да спестите пространство. Също така е важно да се има предвид, че тези програми са предназначени за 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, от която всеки клиент получава индивидуална отстъпка. Размерът на отстъпката се определя от множество параметри, така че е абсолютно невъзможно да се предскаже каква крайна цена ще получи именно вашата компания без запитване до дистрибутора. Но в същото време напоследък нискотехнологичните модели започнаха да се появяват в обикновените компютърни магазини, като например или . В тях можете веднага да закупите интересуващата ви система на фиксирана цена, като всякакви компютърни компоненти.
Но е важно веднага да се отбележи, че пряко сравнение по TB/$ не е коректно. Ако се подходи от тази гледна точка, най-евтиното решение би било прост JBOD + сървър, което няма да осигури нито гъвкавостта, нито надеждността, които предлага пълноценна, двуканална СХД. Това изобщо не означава, че JBOD е нещо лошо, просто е нужно отново да се разбере много ясно — как и за какви цели ще използвате това решение. Често може да се чуе, че в JBOD няма какво да се счупи, тъй като там има само един бекплейн. Но дори и бекплейните могат да се повреждат. Всичко се поврежда рано или късно.
Итого
Системите трябва да се сравняват не само по цена, или не само по производителност, а по съвкупността от всички показатели.
Купувайте HDD само ако сте сигурни, че ви трябват HDD. За ниски натоварвания и несжимаеми типове данни, в противен случай, е добре да се обърне внимание на програмите за гаранция на ефективността на съхранение на SSD, които в момента предлагат повечето доставчици (и те наистина работят, дори в Русия), но тук всичко зависи от приложенията и данните, които ще се съхраняват на тази СХД.
Не търсете евтино. Понякога зад тези предложения се крият множество неприятни моменти, един от които Евгений Елизаров описва в своите статии за . И в крайна сметка, тази евтинотия може да ви излезе скъпо. Не забравяйте — "скупият плаща два пъти".
Източник: habr.com
