Запровадження
Настав час купувати СГД. Яку ж взяти, кого слухати? Вендор А розповідає про вендора B, а ще є інтегратор 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 ми можемо зрозуміти чи потрібен метрокластер, чи досить односпрямованої реплікації. Чи потрібна багатоконтролерна СГД 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 МБ. Дані особливості неможливо вважати технологію багаторівневого зберігання технологією підвищення продуктивності, як помилково вважається багатьма. Багаторівневе зберігання у системах нижнього та середнього класів – це технологія оптимізації вартості зберігання для систем з вираженою нерівномірністю навантаження.
Знімок
Скільки б ми не говорили про надійність СГД, існує безліч можливостей втратити дані, що не залежать від апаратних проблем. Це можуть бути як віруси, хакери або будь-яке інше, ненавмисне видалення/псування даних. З цієї причини резервне копіювання продуктивних даних є невід'ємною частиною роботи інженера.
Снапшот - це знімок тома на якийсь момент часу. Працюючи більшості систем, як-от віртуалізація, БД тощо. нам необхідно зняти такий знімок, з якого ми копіюватимемо дані в резервну копію, при цьому наші ІС зможуть спокійно продовжувати працювати з цим томом. Але варто пам'ятати – не всі снапшоти однаково корисні. У різних вендорів різні підходи до створення снапшотів, пов'язані з їх архітектурою.
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 000 IOPS 8kb блоком 50% випадкового доступу 80/20 читання-запис. 300 ТБ на розробку, там 50 IOPS вистачить, 000 випадковий, 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, які зараз мають більшість вендорів (і вони дійсно працюють, навіть у Росії), але тут все залежить від додатків і даних, які будуть розташовуватися на цій СХД.
Не женіться за дешевизною. Часом під ці ховається безліч неприємних моментів, один з яких Євген Єлізаров описував у своїх статтях про . І що, зрештою, ця дешевизна може вийти вам боком. Не варто забути — скупий платить двічі.
Джерело: habr.com