Кількома місяцями раніше я вже проводив опитування. на тему перспектив переходу користувачів на Clustered Data ONTAP на їх стораджах. Опитування це позначив кілька основних груп користувачів по відношенню до Clustered Data ONTAP.
Якщо з приблизно третю, тими, хто відповів, що вони вже перейшли, або переходять до кінця цього року (ну або в найближчому майбутньому, головне, що рішення вже прийнято), все зрозуміло, я можу їх тільки привітати з їх рішенням, то ось з рештою двома третинами все складніше. Звичайно, я тверезо розумію, що серед оставшхся деякий (значне) кількість складають власники молодших і старих систем, для яких перехід на Clustered Data ONTAP закритий з технічних причин (наприклад - старості, слабкості і непридатності контролерів попередніх поколінь стораджей). Але напевно серед них також є і люди, які, можливо, могли б перейти на Clustered Data ONTAP, але або не розуміють як і коли це зробити, або недостатньо обізнані про те, від яких булочок вони, в результаті, відмовляються. Мені б хотілося, в серії постів, котрі я запланував і написав для найближчих декількох тижнів, детально розібрати ці нові і корисні можливості Clustered Data ONTAP.
.?так, коротко, для тих, хто зовсім все проспав, або ж тільки підключився до читання цього блогу, наприклад збираючись купити сторадж NetApp, або розбираючись з уже купленим:
OS Data ONTAP дозволила побудувати систему зберігання, в якій додавання нових функцій зводиться, по суті, до дописування нового коду в цій OS, що дозволяє швидко і широко модернізувати їх системи зберігання. Такий підхід существено відрізняється від підходу "апаратної реалізації", при якому будь-яке розширення чи зміну функціоналу вкрай болісно і займає у розробника багато сил і коштів (оскільки функціональність виявляється "захардкожена" в "мікросхемах"), і, часто, практично неможливо в уже проданих і встановлених системах. Колись "апаратної", слід уточнити, забезпечувала кращі показники продуктивності і надійності, але сьогодні, з сучасними процесорами, архітектурою і добре налагодженим програмним кодом такої Software-defined Storage вже мало відрізняється за цими параметрами від "апаратних" рішень, але істотно в кращу сторону відрізняється в гнучкості і здатності розширювати функціональність просто оновленням OS.
Тому немає нічого дивного в тому, що кілька років тому NetApp, з виходом Data ONTAP версії 8, почала, майже з нуля, розвивати нову "гілку" своєї OS Data ONTAP, яка позвляет будувати системи зберігання у вигляді багатовузлових кластерних систем. Однак, так як багато користувачів були на той момент не готові до переходу на нову, повністю оновлену архітектуру і OS, то NetApp, розсудливо розсудивши, продовжила підтримку і розвиток своєї "класичної" OS, яка отримала назву 7-mode, так як продовжувала внурь 8.x лінійку гілки 7.х. При цьому, крім Data ONTAP 7-mode, існувала Data ONTAP, "нова", що отримала назву c-mode, або Cluster-mode, зараз же вона стала називатися коротше і зрозуміліше: Clustered Data ONTAP.
Така подвійність "перехідного періоду" існувала на сьогодні вже досить довгий час, однак у всього є кінець, і ось, нарешті, було прийнято рішення, що Data ONTAP 7-mode більше не буде розвиватися. Спершу, ось уже начебто пару років як, в неї перестали додаватися нові фічі, обмежуючись підтримкою і налагодженням вже існували, тобто перевівши її в frozen / stable, а ось тепер, нарешті, було вирішено зробити наступний крок, і що наступний мажорний реліз, виходить в RC вже цієї осені, буде вже толькоClustered Data ONTAP. так що в v8.3 коду 7-mode вже не буде.
Що це означає для всіх нас? Ну, тут є два варіанти. Якщо у вас вже працює в Data ONTAP 7-mode система зі старих серій, тобто раніше FAS2240 і FAS3200, і вас в тому, як вона працює все влаштовує, то тоді немає підстав турбуватися, просто продовжуєте жити і працювати, як жили і працювали до цього. Силою вас ніхто нікуди переїжджати не змусить. У період п'яти років з моменту продажу такі сторажі продовжують повністю і офіційно підтримуватися компанією. При цьому, фактично, стораджі NetApp часто живуть дуже довге життя, я особисто зустрічався з раніше працювали старим пристроєм, що жив на аж на якийсь 6.5.х, тобто понад десятирічної давності випуску. Ну, коптять, торохтіло, обслуговувала свох пару десятків користувачів NFS в університеті. Але працювало.
Але якщо у вас сторадж відносно новий, куплений в межах останніх року-двох, особливо якщо це системи midrange, тобто FAS3200, то, напевно, вам буде цікаво подивитися на те, що ж є сьогодні в Clustered Data ONTAP, і чого у вас немає в Data ONTAP 7-mode.
Перш за все, в Clustered Data ONTAP тепер присутня концепція, під назвою NDO - Non-Disruptive Operations. Практично всі операції, які ви можете виконати на сторадже, наприклад обслуговування його, оновлення OS, заміни контролерів, міграції даних, перенесення томів і навіть віртуальних файлери, SVM, з контролера на контролер, і так далі, можуть виконуватися без переривання йде роботи з даними . У невеликий список винятків входять, наприклад, операції з мережевими кулями SMB, де, за властивостями самого протоколу, при міграції SVM розривається сесія, яку програма має заново ініціювати, наприклад заново раніше відкритий відкрити файл. При цьому будь-які операції NFS або блокових протоколів, iSCSI, FCP, FCoE, відбуваються без переривання роботи з даними, навіть якщо при цьому те з цими даними переїжджає з контролера на контролер.
Наявність в сторадже NDO забезпечує відразу істотне зростання "готовності", або ж, інакше, availability. Хоча ряд операцій можна було виконувати онлайн і в разі класичної 7-mode, наприклад за допомогою Cluster Failover, і вони теж могли бути виконані з мінімальним впливом на доступність, все ж були операції, які вимагали даунтайм. Тепер їх не буде. Навіть відключити дискову полку на працюючому сторадже тепер можна "на ходу".
Тільки в Clustered Data ONTAP з'явилися нові фічі, додані за останні кілька років, наприклад це SMB 3.0, pNFS (NFS 4.1) і деякі інші можливості.
У Clustered Data ONTAP тепер є нормальний multipathing іALUA для iSCSI. А також QoS. BranchCache. Access-based Enumeration для SMB, SSL-secured LDAP. IPv6.
При цьому збереглася велика частина фич, за які ми знаємо і любимо "класичний" Data ONTAP, такі як снепшот, дедуплікація, thin provisioning, клони, IP-based реплікація, RAID-DP, FlashCache і FlashPool. Правда поки еше деякі фічі залишаються в списку work in process. з найбільш помітних це Metrocluster і синхронна реплікація. а також всякі нішеві штучки, типу SnapLock (якщо ви етм не користуєтеся, то вам це не треба). Metrocluster очікується вже восени, у вже згаданій Data ONTAP 8.3.
Ви можете будувати багатовузловий кластери з різних контролерів, з різними дисками на них, і, тим самим, створювати складні інфраструктури зберігання. Без переривання роботи кластера та обслуговування ресурсів мігрірвать дані по кластеру з контролера на контролер, з одного типу дисків на інший. при цьому зі збереженням до них доступу навіть під час міграції. Кластер може обслуговувати як NAS, так і SAN, в тому числі і одночасно, unified, як звично це для 7-mode користувачів.
Довгий час однією з основних проблем була висока ціна інфраструктури, так, до відомих пір, підтримувалася тільки switched конфігурація кластера, при якій Ноди кластера були пов'язані один з одним кластерним інтерконекту через досить дорогий сам по собі 10G Ethernet комутатор Cisco Nexus 5000, причому комутатор був потрібен в будь-якому випадку, навіть якщо у вас в кластері було всього дві ноди. З тих пір багато чого змінилося, по-перше у NetApp з'явився недорогий 10G switch спеціально для cluster interconnect, по-друге стала підтримуватися конфігурація, звана dual-node switchless cluster, яка дозволяє перевести в cluster-mode без використання комутатора, прямим включенням "порту в порт "10G кабелю cluster network звичайну пару контролерів, як раніше вона працювала в звичному, класичному 7-mode. Така конфігурація може бути хорошим стартом для тих, хто хотів би перейти на Clustered Data ONTAP прямо зараз, "по-швидкому", без додаткових інфраструктурних витрат на той же комутатор. Причому, що цікаво, цей варіант нітрохи не позбавляє вас можливості в майбутньому перейти на switched cluster, і додавати до кластеру нові ноди.
"Ну добре", скажете ви мені на це, "але як же нам перейти на Clustered Data ONTAP?". Ну ось тут-то і криється основая заковика, яка змусила NetApp вже кілька років тягнути дві верси своєї OS. Справа в тому, що прямого і легкого "однокнопкового" шляху міграції з 7-mode в Clustered Data ONTAP на сьогодні все ще немає. Так, є ті чи інші тулзи, наприклад так званий 7MMT - 7-mode Migration Tool. але і він вирішує тільки частина завдань. Навіть беручи до уваги того, що він мігрує тільки файлові, NAS-дані, які не мігрує LUN-и, які доводиться переносити вручну, це в будь-якому випадку передбачає, що у вас їсть ще NetApp, конфігурований в кластер, і на який собствено і відбувається перенесення . Немає data-in-place міграції. Тобто вам треба все ваші дані кудись смігріровать або забекапіть, потім наявний сторадж вбити, розібрати, переконфігурувати, створити заново вже в Cluster-mode, і повернути на нього всі ваші дані вже в його новій іпостасі.
Чому це так? Справа в тому, що незважаючи на те, що, як я вже написав вище, у NetApp в Clustered Data ONTAP збереглося більшість фіч "класичної" DOT, всередині вона сильно і радикально інша. .? Зміна були занадто революційні, щоб мати можливість робити data-in-place. У NetApp це відбувається не занадто часто, втім, останній раз такий радикальний перехід був, мабуть, з виходом 7.0 і появою так званих FlexVol і aggregate, замість того, що зараз носить назву Traditional Volumes, і з якими ви, готовий сперечатися, ніколи не зустрічалися в реальному житті (при цьому воно, до речі, до цих пір існує в системі).
Якщо ви не клієнт NetApp і купуєте перший свій сторадж, то у вас все просто насправді. Ви можете замовити відразу систему в Cluster-mode, отримати її, і починати працювати, вже не думаючи ні про які міграціях.
Складніше йде справа, якщо у вас вже є працююча розгорнута система з даними. Причому, як часто буває, для міграції немає ні часу ні коштів. Для таких користувачів у NetApp в Росії є цікава пропозиція, і про нього ми поговоримо в одному з наступних постів.
А поки про те, що ж варто зробити, якщо ви все ж таки зважитеся на міграцію. До осені є ще ціле літо, яке, втім пройде, як завжди, не встигнете озирнутися. Зате це, звичайно, час зниженої активності, і, цілком можливо, у вас вийде викроїти час для того, щоб все правильно підготувати.
По-перше, NetApp підготував спеціальний сайт. орієнтований на адміністраторів, знайомих з системами 7-mode, і збираються переходити на c-mode. Це прекрасна стартова сторінка, на якій зібрано безліч лінків на документацію з усіх аспектів міграції.
Справа в тому, що "класична" консоль 7-mode, вона, все ж, звична, рідна, але досить примітивна, за фактом. Ми, адміни NetApp, з нею зріднилися, але, відверто кажучи, консоль без автодоповнення, без іераріхіческой структури команд, це якийсь примітив.
Проте хороші новини. Нова консоль адміністратора в Clustered Data ONTAP повністю переписана. Автодоповнення по табу, wildcards, глобальні команди, іераріхіческая структура команд - все це тепер є.
Погані новини: багато команд змінилося. Так, в чомусь стало більш логічно, і, незабаром, ви цю логіку зрозумієте, і будете дивуватися тому, як ви могли працювати в "старій" консолі. Однак для полегшення переходу NetApp підготував "Розеттський камінь", документ. в якому кожній старій команді в консолі 7-mode відповідає команда в Clustered Data ONTAP.
Цей документ допоможе розібратися з новою консоллю для досвідчених 7-mode адмінів.
Подивившись курси, починайте крутити консоль і System Manager на симуляторі, пробуйте конфігурувати, звикайте до нового виду системи зберігання. У наступних постах я постараюся розповісти, що NetApp придумав для полегшень міграції на Clustered Data ONTAP для користувачів, і про те, які підводні камені в плані конфігурацій ви можете зустріти на цьому шляху.
Як варіант тим, хто хоче перейти з 7-Mode: можна попросити "взяти в тест" систему зберігання у одного з дистриб'юторів і здійснити при її допомоги переїзд на C-Mode. Говоріть вашому Дісті прямо: ми хочемо переїхати на C-Mode. Якщо система буде вільна і на неї не буде "ажіотажу", то вам звичайно ж її дадуть, тим більше потрібна вона буде не на місяць, а від сили на тиждень. А якщо ви ще дасте відкритий "референс", то можуть і допомогти в переїзді;)
Бажано це проробляти влітку, або відразу після нового року, коли у дистриб'юторів "не сезон", системи зберігання лежать і припадають пилом, не задіяні, на поличках.
Про це варіанті я збирався окремо розповісти в наступному пості серії :)
Хочу внести невелике доповнення: для мене Cluster ONTAP буде закрита поки вона вимагатиме окремого root-агрегату на кожну ноду. На системах з однією-двома дисковими полками такі витрати просто не розумні.
Сподіваємося, що в 8.3 зроблять можливість розміщення root-даних на агрегатах з даними.
Роман, що скажете?
Про нову схему виділення місця під root aggregate я теж розповім в одному з наступних постів. Розповім на пальцях і неофіційно, бо до виходу 8.3 восени в деталях це розповідати складно. Але така робота ведеться.
Поки ж ми йдемо у темі безпекової міграції від загального до конкретного. Безумовно, для власників маленьких малодіскових систем схема з обов'язкові виділенням мінімум 3 дисків на контролер під root aggregate - здається расточітетьной, але не забувайте, що для власників систем з, припустимо, п'ятьма полками діскв на контролер, це буде не настільки критично.
Офіційно очікується метрокластер в кластермоде, синхронна реплікація в якому, в загальному, є необхдімо компонентом. Як вже це буде реалізовано - поки гадаємо. Але, думаю, що - так.
уточню:
в 8.3.0 буде спрощення ситуації з root-агрегатомі для молодших моделей, де це найбільш відчутно. На інших системах це буде трохи познее. Але поки до осені говорити рано.
Так само в 8.3.0 буде доступний метрокластер, що забезпечує RPO = 0. Це відповідь на вимогу синхронної реплікації. Але теж треба чекати деталей не раніше середини осені, як мінімум.
Але це все екстремальні випадки. .? не варто на цьому зациклюватися.
Роман, де ж продовження?
Нам, здається, належить міграція на cDOT.
.? у нас FC. Для міграції LUN передбачається яке-небудь рішення?
"Сеня, смажте рибу. Риба - буде! "(С) Одеса
Продовження буде. Просто, на жаль, поточні події і оперативна "текучка" часто відтісняють в блозі фундаментальні теми на периферію.
[. ] В минулий раз ми почали чіпати тему переходу з Data ONTAP 7-mode, на Clustered Data [. ]
БЛОГ ПІДТРИМУЄ:
This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.