Комутатор може померти, а ваше сховище працює далі
Диск вашої VM живе на виділеному масиві, досяжному через дві мережі сховища, які не ділять нічого. Обидві живі весь час, тож мертвий комутатор, висмикнутий кабель або ціла мережа, виведена на обслуговування, є non-event для навантаження.
У цій статті 4 розділів
- Кожен хост у нашому SAN досягає свого сховища через дві повністю незалежні fabric Fibre Channel, з окремими комутаторами, у режимі active/active.
- Комутатор, кабель або порт може вийти з ладу, і ваш LUN працює далі іншим шляхом. Обидва шляхи несуть production I/O весь час, тож немає резерву, який треба будити, і немає cutover, який треба пережити.
- RAID усередині одного сервера покриває одну відмову, мертвий диск. Усе інше в цій коробці забирає ваше сховище із собою.
- Дизайн дозволяє вивести цілу fabric з експлуатації, поки кожна віртуальна машина працює на іншій.
Диск, на який пише ваше навантаження, не живе всередині сервера, який його виконує. Він живе на масиві сховища за мережею, і ця мережа може відмовити, як і будь-що інше: комутатори помирають, кабелі висмикують, порти починають «блимати». Що вирішує, чи помітить ваше навантаження хоч щось, це чи є друга дорога до диска, і чи справді ця друга дорога окрема від першої.
Multipath дає кожному хосту дві живі дороги до його LUN
LUN є блоковим пристроєм, який ваша віртуальна машина бачить як свій диск. У SAN цей диск живе поза сервером, який виконує ваше навантаження, на виділеному all-flash масиві з двома контролерами, і сервер досягає його через мережу сховища. Multipath означає, що сервер тримає більше ніж один фізичний маршрут до того самого LUN одночасно, через різні порти, різні кабелі й різні комутатори.
Active/active означає, що обидва маршрути несуть трафік кожну секунду дня. Резервний шлях, який прокидається лише під час відмови, є шляхом, який ви ніколи по-справжньому не тестували, а відмова є найгіршим можливим моментом для його першого тесту. Коли обидва шляхи постійно несуть живий I/O, втрата одного просто залишає інший робити всю роботу, половину якої він уже робив. Навантаження не бачить нічого, бо з того місця, де воно сидить, нічого не сталося.
Два порти HBA на хості
Два кабелі, двома окремими трасами
Два комутатори, по одному на fabric
Дві fabric Fibre Channel, обидві active/active
Дві fabric не ділять жодного комутатора, тож відмова не може перейти між ними
Два шляхи через той самий комутатор є одним шляхом під двома мітками. Що вбиває комутатор, вбиває обидва. Справжня незалежність означає, що дві fabric побудовані як дві окремі мережі з окремими комутаторами, і ніщо на шляху даних між хостом і масивом не з’являється в обох. Збій в одній fabric, чи то мертвий комутатор, чи порт, що «блимає», чи перевантажена лінія, не має куди поширюватися. Друга fabric про нього не чує.
Fabric Fibre Channel є комутованою мережею між серверами і масивами сховища, еквівалентом вашої LAN для сховища. Мати дві, повністю окремі, означає, що ваш трафік сховища завжди має другу мережу, у якій жити. Дорогі відмови в мережах сховища рідко є чистими смертями; це лінії, які лишаються up, але застрягають, і незалежність є тим, що тримає таку хворобу на одному боці.
RAID усередині одного сервера помирає разом із сервером
RAID на контролері всередині вашого сервера захищає вас рівно від одного, мертвого диска, і робить це добре. Але диски, карта RAID, backplane, блоки живлення і материнська плата живуть в одній коробці, і коробка є доменом відмови. Коли в ній помирає будь-що інше, ваше сховище зникає разом із ним і повертається тоді, коли повертається сервер. Якщо виходить з ладу сама карта RAID, найздоровіші диски у світі недосяжні.
SAN виносить диск за межі домену відмови машини, яка його використовує. Ваш сервер може померти, а LUN, на який він писав секунду тому, досі там, цілий і працює, готовий до того, щоб навантаження повернулося на іншому хості. Дизайн із двома fabric поширює ту саму ідею на дорогу між ними: шляху до вашого сховища теж дозволено відмовити, тож ми побудували два.
| Що відмовляє | Що бачать ваші навантаження |
|---|---|
| Кабель або порт | LUN працює далі іншим шляхом. Без cutover, без перезапуску. |
| Цілий комутатор | Друга fabric несе все. Ніщо не прокидається і не перемикається. |
| Ціла fabric, виведена на обслуговування | Кожен хост тримає добрий шлях на здоровій fabric, поки триває робота. |
| Вузол контролера сховища | Другий контролер працює далі, поки обладнання міняють. |
| Сам сервер | LUN його переживає. Навантаження перезапускається на іншому хості і знаходить свій диск там, де його лишило. |
Вивести цілу fabric з експлуатації під живими навантаженнями
Коли fabric потребує обслуговування, процедура негламурна: підтвердити, що кожен хост тримає добрий шлях на іншій fabric, вивести fabric з експлуатації, виконати роботу, потім свідомо повернути її. Віртуальні машини працюють на одній fabric, поки триває робота, і не бачать нічого. Це правильна кількість драми для обслуговування сховища.
Та сама позиція тримається і на боці масиву. Масиви мають по два контролери: один контролер можна обслуговувати, поки інший працює далі. Обладнання в нашому SAN обслуговується так, як має обслуговуватися всюди: поки річ, якій воно належить, продовжує робити свою роботу.
Прямі відповіді
Active/active є просто гарнішим словом для failover?+
Ні. Дизайн failover тримає другий шлях бездіяльним, доки перший не помре, а потім намагається зробити cutover у найгірших умовах дня. Active/active означає, що обидві fabric несуть production I/O весь час, тож відмова прибирає один робочий шлях, тоді як інший робочий шлях продовжує. Немає події cutover, яку треба пережити, і немає резерву, який отримує свій перший тест під час вашого інциденту.
Мій сервер має RAID-10. Це той самий захист?+
RAID усередині сервера захищає ваші дані від мертвого диска, і лише від нього. Карта RAID, backplane, блоки живлення і сам сервер лишаються єдиними точками відмови, і ваше сховище ділить їхню долю. У SAN сховище переживає смерть сервера, який його використовує, а з двома fabric воно переживає і смерть дороги між ними.
А якщо відмовить увесь масив або весь майданчик?+
Інший клас відмов, інші інструменти. Ця стаття покриває шляхи між здоровим хостом і здоровим масивом, де живуть повсякденні відмови. Пережити втрату масиву або майданчика є розмовою про відновлення, і ми описали її окремо: скільки втрати даних і простою ваш бізнес може чесно витримати.
Як я знаю, що обидва шляхи справді працюють, до того як один відмовить?+
Оскільки обидві fabric постійно несуть живий I/O, мертвий шлях не є тихим станом: тієї миті, коли один бік перестає рухати трафік, це спливає в моніторингу. І кожне обслуговування починається однаково, з підтвердження, що кожен хост тримає добрий шлях на fabric, що лишається, перш ніж щось виводити з експлуатації.
Запитайте інженера, на чому насправді стоїть ваше сховище
Люди, які проєктують і експлуатують fabric, є тими самими людьми, які відповідають. Принесіть свою поточну конфігурацію, і ми прямо скажемо, що що переживає.
Поговоріть з інженеромМертві комутатори, висмикнуті кабелі й обслуговування контролерів є відмовами, які цей дизайн виводить із гри. Втрата цілого масиву або цілого майданчика є іншим класом відмов, і той починається з розмови про відновлення. Якщо ви оцінюєте хостів, питання про сховище, які варто ставити будь-кому, включно з нами, є у брудна таємниця вашого хоста: його сховище.
Ви дійшли до кінця.
Застосуйте прочитане на практиці
Що ви запускаєте?
Розкажіть нам про навантаження, трафік і вимоги до відновлення. Почніть з конструктора сервера або обговоріть деталі з інженером.
Написано інженерами, які будують і експлуатують інфраструктуру, про яку йдеться.Поговоріть з інженером