Кращі практики для віртуалізації серверів на SAN?

Гаразд, тому я хочу почати використовувати свій SAN трохи більше, ніж я, і в той же час скористатися ESXi.

На даний момент у мене є масив лез Dell PowerEdge 1955, підключений до масиву зберігання EMC AX4-5 FC з одним корпусом. Я по суті використовую SAN як DAS. Я маю LUN на SAN, які вказують на конкретні фізичні машини, і ці машини використовують LUN для будь-якого (в основному бази даних та спільних даних Samba / NFS, залежно від цільового сервера).

У мене є декілька фізичних файлових серверів, і кожен з них має налаштування конфігурації samba для обслуговування відповідних спільних ресурсів. Оскільки я ніколи не працював із RHCS, лише один із файлових серверів одночасно монтував LUN. У випадку, якщо файл-сервер гине, я забороняю його вручну (або від'єднавши та не представивши привід, використовуючи утиліту navisphere, або вбивши живлення через DRAC), потім використовую утиліту navisphere, щоб вивести представлені LUN на наступного суперника ( після чого запускайте апачі та інші демони). Все вручну, прямо зараз.

Мені здається, що Ферріс Буллер грає на кларнеті. Ніколи не було уроку!

У всякому разі, я намагаюся вдосконалитись. Що я хочу зробити, це встановити ESXi на фізичних хостах, а потім створити LUN для зберігання двох зображень файлового сервера (у випадку, якщо один стане пошкодженим / фубаром), одне з яких буде активним, а інше - в режимі очікування. Принаймні таким чином, я не вдосконалюю автоматизацію (хоча незабаром я змушусь написати сценарій для переключення "активного" сервера), але відчуваю, що додаю гнучкість, плюс я можу використовувати ESXi розміщує інші VM, і апаратне забезпечення не витрачається даремно, як зараз.

Мої запитання:

1) Наскільки дурний мій план?

2) Якщо мова заходить про фактичну реалізацію, чи слід створити нормальне зображення vmdk на LUN або мені слід надати йому "сирий" розділ (якщо це можливо навіть з ESXi?)

3) Чи існує "хороший" спосіб використання некластеризованих файлових серверів?

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

По-перше, ви можете подати необмежену LUN у VM за допомогою "Сирого картографування пристроїв". Зробити це:

• Подаруйте LUN ​​хосту ESXi (або хост-групі, якщо ви збираєтесь використовувати кластеризацію / HA)
• Додайте диск у свій ВМ, виберіть «Неочищене картографування пристроїв», наведіть курсор на LUN
• Перегляньте шину SCSI всередині VM
• fdisk, змонтуйте та додайте до fstab, як і звичайний диск.

Вгору: швидкий у налаштуванні, швидкий у використанні, простий, може представляти диск фізичному хосту, якщо вам доведеться V2P вниз по трасі

Знизу: ви можете втратити деякі варіанти знімків / відкатів на основі VMware, залежно від того, чи використовуєте ви фізичний або віртуальний режим сумісності

Альтернативний варіант - створити VMFS в LUN для створення сховища даних, а потім додати диск VMDK до VM, що живе в цій сховищі даних.

• Вгору: це зберігання vMotion зручно, якщо ви коли-небудь купуєте ліцензію на його використання. Це дозволяє здійснювати гарячу міграцію дисків VMDK між LUN та навіть SAN.

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

Я не розгортаю RDM, якщо мені не доведеться; Я виявив, що вони не купують мені великої гнучкості як VMDK (і мене покусали помилки, які зробили їх непрактичними під час виконання інших операцій зберігання (оскільки виправлено - див. Розділ RDM у цьому посиланні))

Що стосується вашого VM, то найкраща ставка на гнучкість - зберігати завантажувальний диск вашого файлового сервера як VMDK в SAN, щоб у вас могли бути інші хости завантажувати його у разі відмови хоста. Використовуючи функціонал HA від VMware, завантаження VM на іншому хості є автоматичним (VM завантажиться на другому хості так, ніби витягнуто живлення; розраховуйте виконати звичайний fsck і магію, щоб підняти його, як у випадку звичайного сервера ). Зауважте, HA - це ліцензована функція.

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

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

Я б дотримувався зображень vmdk, просто, якщо ви перейдете до використання vmotion у майбутньому, ви ніколи не знаєте, що можете отримати бюджет на це.

Якщо ваші машини не кластеризовані, то, наскільки я переживаю, найкращий спосіб управління ними - спробувати розподілити навантаження максимально рівномірно. У мене є 3 негруповані 2950, ​​де навантаження від найважливіших VMS становить якомога більше 1/3 на кожну. Зважаючи на те, що я навряд чи втрачую більше одного ящика одночасно, тож щонайменше 2/3 зможуть продовжувати працювати без змін.

З точки зору живлення, напевно, було б ефективніше завантажувати машини приблизно на 100%, як ви можете, і вимкнути інші машини, але мені здається, що ви покладете всі яйця в один кошик.

Я б не назвав себе експертом у цьому, це саме те, що я роблю.

Гей Метт. Існує маса способів розрізати рішення, коли ви використовуєте рішення для віртуалізації. По-перше, було багато орієнтирів, що показують Raw LUN (RDM) порівняно з продуктивністю VMDK, і різниця, як правило, виявляється незначною. Деякі речі, які слід пам’ятати про RDM: Використання RDM (MS кластеризації) вимагає лише певних ситуацій кластеризації. RDM мають обмеження 2TB, але для обходу цього ліміту можна використовувати LVM. RDM 'важче' відслідковувати, ніж давати LUN ESXi для використання у VMFS та ставити на нього vmdk. VMDK (як уже згадувалося) має деякі приємні переваги: ​​svMotion, Знімки (не вдається зробити знімок pRDM).

Якщо ви працюєте з безкоштовним ESXi, ось як я можу розповісти про вашу ситуацію. Спочатку всі дані знаходяться у файлах vmdk на VMFS LUNS. Установіть 2 VM та використовуйте Heartbeat для відмови від IP-послуг та служб. Серцебиття змістить IP-адресу служби і може обробляти сценарії, щоб демонтувати / змонтувати дані LUN, де це доречно. Ви навіть можете написати сценарій деяких віддалених CLI VMware, щоб переконатися, що «вниз» VM вимкнеться для забору. Якщо серцебиття безпосередньо координується між системами, ризик як отримати доступ до ланцюга даних, так і працювати на одних і тих же службах повинен бути вкрай низьким. Тут головне - переконатися, що монтуванням / демонтажем даних LUN та запуском / вимкненням послуг керує Heartbeat, а не звичайні механізми init.

Альтернативний варіант відмови може бути здійснено за допомогою системи моніторингу. Якщо він виявить спадний хост, він може використовувати VMware Remote CLI для вимкнення живлення (щоб бути безпечним), а потім включити резервне копіювання vm. У цій ситуації відмова назад є досить ручною.

У моєму «крихітному» середовищі я не бачив, щоб VMDK псувався. Я також зрозумів, що якщо у вас є більше 2 хостів ESX (i) або десяток VM, ви захочете отримати vCenter, щоб допомогти відстежувати все. Деякі пакети Essential / Plus не надто дорого враховують переваги.

Метт, ти знаєш, що я не використовую VMware, але я завжди використовував "RAW" з Xen. Маючи кілька завантажених машин, які легко завантажуються, я сумніваюся, що ви побачите велику різницю у продуктивності. Але коли ви почнете відвідувати все більше й більше гостей, якщо всі ці гості мають однакову файлову систему, у вас з’являться проблеми з глибиною черги. Особливо це стосується резервного зберігання NFS. Це не так багато проблем з сервером NFS, але більшість реалізацій клієнтів NFS вичерпані.

Я не знаю хорошого способу синхронізації vmdks, якщо ви шукаєте надмірності (san neusp.). Але якщо ви використовуєте блокові пристрої, у вас все ще є можливість використовувати DRBD для реплікації лише тих, які ви хочете / потребуєте реплікувати.

Я думаю, ви повинні запитати себе: "Чи планую я коли-небудь повернутися до фізичних серверів"

Якщо відповідь, можливо, тоді, можливо, ви повинні дотримуватися RDM. ESXi з RDM вимагає, щоб ви придбали щось для того, щоб ваше волокно працювало (знову ж таки не на 100% впевнене, що стосується esxi).

У нас було кілька машин, які я просто швидко перейшов з фізичних серверів в ESX (4.0) за допомогою RDM. У мене було поєднання машин Linux та Windows (дуже просто для обох платформ). На фізичних серверах у нас є кілька запущених легенд FreeBSD (6.0 і старші), для яких ми не можемо використовувати RDM, оскільки старе ядро ​​FBSD це не підтримує. Це було швидко і вимагало від мене нічого, крім вказувати свій LUN, а потім встановлювати інструменти VMWare. Мозок мертвий легко .. немає перетворювача, не суєти ...

Ще одна річ, яку ви повинні запитати у себе: "Які функції VMWare я хочу використовувати?"

Залежно від вашої відповіді на це, можливо, у вас немає іншого вибору, крім VMDK. Якщо ви використовуєте свій SAN для знімків, і не дбаєте про використання vmware для цього, наприклад.

Деякі зауваження Я ділюся з вами про те, у що ми стикалися до цих пір .. Vmotion однаково чудово працює з RDM і VMDK, Storage Vmotion з іншого боку працює правильно лише з не RDM, і намагається використовувати Vmotion зберігання, щоб перейти від RDM до VMDK смокче просто використовуйте конвертер. Більшість дистрибутивів Linux має пакет інструментів з відкритим кодом vmware, що робить встановлення інструментів не проблемою. Резервне додаток працює дуже добре і не містить віртуального програмного забезпечення, але не робить стільки речей, як нам би хотілося. Я дуже рекомендую взяти клас з vmware. Я взяв тиждень і коштував кожної копійки підтримки VMWare - це приголомшливо. Якщо ви отримаєте контракт на підтримку і вам потрібно зателефонувати, вони є найвищими .. Я зриваюся потрапляти до когось, хто може мені допомогти (до багатьох меню .. ), але як тільки я їх отримую, вони ВЖЕ завжди приходять, хоча зі швидкою надійною підтримкою.