Вибір технології SAN для 100-ти веб-серверів VM

Проблема

У нас є проблема з продуктивністю на існуючій платформі, тому я звертаюся до вулика, щоб отримати другу думку з цього приводу. Випуск ефективності поки що стосується IOPS, а не пропускної здатності.

Сценарій

Центр леза з 16 хостів, кожен з 64 Гб оперативної пам’яті. (Це Dell M1000e w / M610, але це, мабуть, не стосується) 500 VM, усі веб-сервери (або пов'язані з ними веб-технології, такі як MySQL, балансири завантаження тощо), приблизно 90% - це Linux, а решта Windows. Гіпервізор - це VMWare vSphere. Нам потрібно забезпечити хост HA, тому локальне сховище вимкнене. Як такий хост просто має SD-карту для завантаження.

Трохи фонового мислення

На даний момент ми маємо до 6 хостів (центр лез буде за повним потенціалом через рік при поточному зростанні) і ми запускаємо iSCSI до Dell MD3220i w / MD1220 для розширення.

Можливі варіанти, які ми розглянули, і негайні думки разом з ними:

• Поширення віртуальних машин у сховищах даних NFS та запуск NFS-накопичувача, що відповідає вимогам продуктивності до заданої кількості віртуальних машин. NFS здається дешевшим для масштабування, а також був абстрагований трохи більше, ніж сховище на рівні блоку, тому ми можемо переміщувати його за потребою.
• Додавання більше контролерів / цілей MD3220i. Ми, проте, стурбовані тим, що це може якось негативно вплинути на те, як VMWare обробляє багато цілей.
• Заміна всіх дисків з Nearline SAS на SSD. Це повинно повністю вирішити проблему IOPS, але має очевидний побічний ефект зменшення нашої ємності. Крім того, це все ще дуже дорого.
• vSphere 5 має пристрій для зберігання даних. Ми не так багато досліджували, але це має добре працювати?

Питання

Яке сховище ви б працювали під усім цим? Він не потребує масштабування до іншого центру леза, він просто повинен забезпечити відносно хороші показники для всіх цих віртуальних машин.

Я не шукаю відповідей "Купити SAN x, тому що це найкраще". Я шукаю думки щодо різних технологій SAN (iSCSI, FC, FCoE, InfiniBand, NFS тощо), різних типів зберігання даних (SATA, SAS, SSD) та методологій для зберігання даних для 100-ти VM (консолідація, розділення). , Шардінг тощо).

З цього приводу можуть вітати будь-які думки, посилання, посібники, вказівки тощо. Я також хотів би почути думки щодо вищенаведених варіантів, які ми вже розглядали.

Заздалегідь дякую за будь-який внесок!

Оновлення 5 березня '12

Дотепер кілька фантастичних відповідей, дуже дякую всім!

Ідучи до цих пір відповідей на це питання, я починаю вважати наступним маршрутом:

• Підключіть наявне сховище до кластера VMWare та розмістіть диски VM на відповідному сховищі для їх завантаженості.
• Потенційно використовуйте SAN, який здатний автоматично управляти розміщенням даних на відповідному сховищі.
• Infiniband виглядає найвигіднішим, щоб отримати необхідну пропускну здатність з хостами на повну потужність.

Це, безумовно, звучить так, що варто скористатися послугами передпродажного обслуговування великого постачальника SAN, щоб прийняти їх за сценарій.

Я ще деякий час буду розглядати цю проблему. Тим часом більше рад із вдячністю отримано!

Запорукою хорошої платформи зберігання VMWare є розуміння того, яке навантаження створює VMWare.

• По-перше, оскільки ви розміщуєте багато серверів, завантаженість, як правило, випадкова. Одночасно відбувається багато потоків вводу-виводу, і не багато з них можуть бути успішно попередньо кешовані.
• По-друге, він мінливий. Під час звичайних операцій ви можете побачити 70% випадкових зчитувань, однак, як тільки ви вирішите перенести VM в нову сховище даних або щось подібне, ви побачите масивну послідовність запису в 60 Гб. Якщо ви не обережно ставитеся до архітектури, це може порушити здатність вашого сховища обробляти звичайний IO.
• По-третє, невелика частина вашого середовища зазвичай генерує велику частину робочого навантаження для зберігання.

Найкращий спосіб підійти до створення сховища для платформи VMWare - це почати з основ.

• Вам потрібна можливість обслуговувати велику випадкову роботу зчитування, що означає менші швидші диски, а також, можливо, SSD. Більшість сучасних систем зберігання даних дозволяють автоматично переміщувати дані залежно від способу доступу. Якщо ви збираєтеся використовувати SSD, ви хочете переконатися, що саме так ви його використовуєте. Це має бути як спосіб поступового зменшення гарячих точок. Незалежно від того, використовуєте ви SSD чи ні, корисно мати змогу розмістити всю роботу на всіх накопичувачах, тому щось із типом об’єднання сховища буде корисним.
• Вам потрібна здатність обслуговувати переривчасті великі записи, які не так сильно переймаються швидкістю шпинделя базових накопичувачів, але дбають про ефективність стека контролера та розмір кешу. Якщо у вас є дзеркальне кешування (що є необов'язковим, якщо ви не готові повертатися до резервного копіювання кожного разу, коли у вас відмова контролера), пропускна здатність між двома кешами, які використовуються для дзеркального відображення, зазвичай буде вашим вузьким місцем для великих послідовних записів, як правило. Переконайтесь, що все, що ви отримуєте, має високошвидкісний контролер (або кластер) для кешування запису. Зробіть все можливе, щоб отримати високошвидкісну мережу на передньому кінці з якомога більшою кількістю портів, залишаючись реалістичними щодо ціни. Запорука хорошої продуктивності переднього торця полягає в тому, щоб розмістити ваші сховища на якомога більше ресурсів переднього кінця.
• Ви можете серйозно знизити витрати, встановивши рівень для зберігання з низьким пріоритетом, а також тонке резервування. Якщо ваша система не автоматично мігрує окремі блоки на дешеві великі / повільні накопичувачі (наприклад, біля лінії SAS або SATA з розмірами 7200 RPM та 2TB +), спробуйте це зробити вручну. Великі повільні диски - прекрасні цілі для архівів, резервного копіювання, деяких файлових систем і навіть серверів із низьким рівнем використання.
• Наполягайте, щоб сховище було інтегровано VAAI, щоб VMWare міг розподілити невикористані частини віртуальних машин, а також сховища даних.

Мої великі розгортання VMWare - це NFS та iSCSI понад 10GbE. Це означає двопортовий 10GbE HBA на серверах, а також голову зберігання. Я прихильник зберігання на основі ZFS. У моєму випадку це обгорнуто навколо комерційного NexentaStor , але деякі вирішують прокрутити своє.

Основними особливостями зберігання на основі ZFS в цьому контексті буде функція кешування ARC / L2ARC, що дозволяє вам зберігати рівень зберігання. Найактивніші дані знайдуть свій шлях у оперативній пам’яті та накопичувачі SSD як другого рівня. Також буде корисним запуск вашого основного пулу пам’яті від 10 кб або 15 кб накопичувачів SAS.

Це ще один випадок профілювання та розуміння вашої роботи. Працюйте з тим, хто зможе проаналізувати ваші шаблони пам’яті та допоможе спланувати. Що стосується ZFS / NexentaStor, мені подобається PogoStorage . Без такого типу розуміння транспортний метод (FC, FCoE, iSCSI, NFS) може не мати значення. Чи є у вас моніторинг наявної інфраструктури? Як виглядає діяльність вводу / виводу зараз?

Ключове питання: "де вузьке місце?" Ви згадуєте IOPS, але чи це означає, що ви позитивно визначили самі диски як вузьке місце, або просто те, що порти SAN не працюють на потужності, або що VM мають набагато більше часу, ніж ви хотіли?

Якщо ви точно визначили, що диски є обмежуючим фактором, тоді для переходу на NFS або infiniband або що-небудь не збираєтеся робити присідання для вашої продуктивності - вам потрібні SSD (або принаймні багатоярусне сховище з SSD в суміші) або цілий набір більше шпинделів (рішення, яке недавно стало набагато дорожчим з моменту, коли всесвітнє виробництво крокових двигунів вимилося в океан).

Якщо ви не впевнені на 100%, де насправді вузьке місце, вам потрібно знайти це спочатку - замінювати частини своєї інфраструктури для зберігання більш-менш на випадковий вигляд, на думку інших людей, тут не буде дуже ефективний (особливо враховуючи, наскільки дорогі будь-які зміни будуть впроваджуватися).

Якщо ви хочете використовувати iscsi або nfs, то мінімально вам потрібно кілька портів 10/40 Гб або infiniband, що є найдешевшим варіантом, але, начебто, рішення для зберігання для infiniband здаються обмеженими. Проблемою буде модуль для bladecenter, які його варіанти, як правило, 8gb fc або 10 \ 1gbe і, можливо, infiniband. Зауважте, що infiniband можна використовувати з nfs і нічого не закривається для нього з точки зору продуктивності \ ціни. якщо блейд-центр підтримує qdr infiniband, я би зробив це з якоюсь Linux-хосткою з tca qdr infiniband через nfs. Ось хороше посилання, що описує це http://www.zfsbuild.com/2010/04/15/why-we-chose-infiniband-instead-of-10gige

але якщо bladecenter може підтримувати qdr infiniband, і ви можете дозволити собі рідний infiniband, то це рішення, яке ви повинні вибрати.

В даний час ви можете отримати 40gbe комутатори набагато дешевше (це дивна думка), то 10gbe комутатори, але я сумніваюся, що центр леза підтримає це.

Місцеве сховище немає? Я цілком задоволений пропускною спроможністю запису на моєму локальному RAID 5s - дзеркальному відображенні з DRBD8 кластеру-партнеру моєї машини XEN ... (але це, звичайно, не підтримується).

Окрім цього, я цілком впевнений, що mySQL - це ваша продуктивність (я ніколи не бачив гіршої БД). Спробуйте налаштувати його та / або спробуйте помістити весь БД у кеш файлової системи (для доступу для читання) ...