Яке сховище фактично використовують люди для серверів VMware ESX?

VMware та багато мережевих євангелістів намагаються сказати вам, що складні (= дорогі) волокна SAN - це "єдиний" варіант зберігання для серверів VMware ESX та ESXi. Ну так, звичайно. Використання SAN швидко, надійно і робить vMotion можливим. Чудово. Але: Чи можуть усі користувачі ESX / ESXi дійсно дозволити собі SAN?

Моя теорія полягає в тому, що менше 20% усіх установок VMware ESX на цій планеті фактично використовують волокна або iSCS SAN. Більшість цих установок буде у великих компаніях, які можуть собі це дозволити. Я б передбачив, що більшість установок VMware використовують "додане сховище" (vmdks зберігаються на дисках всередині сервера). Більшість з них працюють у малих та середніх підприємствах, і їх так багато!

Ми запускаємо два сервери ESX 3.5 із доданим сховищем та два сервери ESX 4 із iSCS san. І "справжня різниця в живому" між обома ледве помітна :-)

Чи знаєте ви якусь офіційну статистику з цього питання? Що ви використовуєте як носій інформації?

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

Ви, звичайно, можете запускати дуже високопродуктивні VM з безпосередньо приєднаного сховища (HP DL380 G6 з 16 внутрішніми накопичувачами в масиві RAID 10 матиме досить швидкий IO диск), але якщо ви створюєте VMware або будь-яке інше віртуалізоване середовище, щоб замінити десятки, сотні або тисячі серверів, то ти божевільний, якщо не вкладаєш багато зусиль (і, можливо, грошей) у надійну архітектуру зберігання.

Вам не потрібно купувати високоякісний SAN для функцій кластеризації - ви можете реалізувати їх за допомогою досить дешевого NAS (або віртуалізованого SAN, наприклад VSA HP \ Lefthand), і все ще використовуєте сертифіковане сховище. Однак якщо ви використовуєте спільне сховище, і воно не має надмірності в усіх точках інфраструктури SAN \ NAS, тоді ви не повинні використовувати його набагато більше, ніж для тестування. А надмірність - це (як мінімум) подвійні (незалежні) HBA \ NIC-пам’яті зберігання на ваших серверах, подвійні незалежні тканини, надлишкові контролери в SAN, керований кеш-пам'ять кеш \ кеш-дестанг, надлишкові гарячі замінники вентиляторів та джерела живлення тощо, RAID 5 \ 6 \ 10 \ 50 та відповідна кількість гарячих запасних частин.

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

Як компанія, у якої понад тисяча хостів, ми розпочали роботу з FC, деякий час спробували iSCSI, але відступили до FC через проблеми з продуктивністю. Ми серйозно дивимось на NFS, але поки не маємо висновків. О, і ми використовуємо HP XP / EVA та деякі NetApp, у нас немає локальних хостів для зберігання настільних ПК / розробників.

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

Що стосується високої продуктивності, що пише і читає, я виявив ФК неперевершеним у своїй продуктивності, і в той час як ціна висока ... Це просто працює ... для більш повних очікувань щодо продуктивності iSCSI насправді працює досить добре, тому я, як правило, отримую обмінні файли поштової скриньки сервера в підсистемі FC-диска та фактичні завантажувальні диски на інтерфейсі диска інтерфейсу iSCSI, при цьому сервери DNS та машини Active Directory також працюють із iSCSI.

Я працював ESX з SAN, NAS та DAS. Це повністю залежить від:

1. бюджет
2. досвід
3. центр обробки даних та / або стійка
4. гроші

Щодо надійності та швидкості, я не думаю, що ти можеш перемогти SAN.

Для надійності та вартості я б поїхав з NAS.

А для швидкості та вартості, DAS.

Не те, щоб окремі варіанти не перекривали деякі, але це сильні сторони, якими я був свідком.

Ми запускаємо 4 сервери ESX 4 та використовуємо iSCSI SAN EqualLogic.

На менших установках локальне сховище цілком прийнятно, якщо у вас є пристойні диски - я б сказав, 10 кп RPM + диски SAS. Єдиний раз, коли Ви ОБОВ'ЯЗКОВО використовувати спільний диск (я навмисно не сказав сан, оскільки ваш спільний диск може бути вимкнено, а NFS - це рішення), коли вам потрібно зробити кластеризацію - VMWare HA та DRS.

На даний момент у нас є 3 яруси зберігання даних - FiberChannel SAN, SAN високого класу Equalogix SAN і низькі кінці MD3000i SAN. Останні два - iSCSI. Ми також запускаємо деякі сервери на локальному сховищі серверів ESX - в основному сервіси утиліт, які нам не байдужі, чи вони стоять на годину-дві, поки ми виправляємо речі, якщо все почне швидко розвиватися.

Ми також проводимо тестову обстановку з побудованого NAS, використовуючи 7,2k SATA-накопичувачі та цільову корпоративну ціль iSCSI (продуктивність не все гарна, але нас це отримує).

Багато людей прагнуть також протистояти акціям NFS у великих середовищах. Я хотів пограти з цим деякий час, але не знайшов часу.

Ми запускаємо чотири (ну, чотири живі, один для тестування), хости ESXi з тканиною iSCSI, побудованою з товарних комутаторів, і Hitachi SAN низького рівня - SMS-100.

Навіть на цьому рівні у нас є контролери-близнюки, кожен з яких є порти-близнюки на опорній площині SAS, щоб будь-який контролер міг захоплювати диски, і близнюки - які ми перетинаємо дріт на двійні комутатори, а також на близнюки в ESX хостах.

Кожен з томів vfs має чотири видимих ​​шляхи, тому він є досить толерантним. Ми використовуємо Dell перемикачі живлення для тканини - у них можливі проблеми напевно (щонайменше, немає зайвих блоків живлення) .. але вони також досить дешеві, що наявність двох заздалегідь налаштованих запчастин у коробці, готовій для заміни, стає реальною можливістю.

очевидно, якщо ви хочете більше дев'яти, вам потрібно витратити більше грошей, але я думаю, що краса iSCSI, ESXi та товарного гігабітного ефірного набору полягає в тому, що ви можете досягти своєї ваги з точки зору стійкості та продуктивності.

У всіх є свої плюси і мінуси ... Підсумковий рівень - це угода про домовленість, навантаження програми та масштаб. Отже, якщо вам потрібне високоефективне сховище для невеликого розгортання (1-5 хостів), ви, ймовірно, могли витягнути його за допомогою NFS (я фактично колись досяг кращої затримки з NFS, ніж з SAN з використанням RAM-дисків). Тепер спробуйте масштабувати це, і ви побачите, що вартість повторення вашої установки в масштабі дуже порівнянна з приємним SAN, що робить FC єдиним логічним варіантом для ознайомлення ... Більшість часу я в кінцевому підсумку використовую комбінації для різних служб (додатків , БД, резервні копії, архіви) не єдина платформа для оптимізації витрат, залежно від потреб.