Не планування змін в апаратне забезпечення.
Включити EVC режим на кластерах, і намагатися використовувати обладнання, яке має дуже схожі процесори. Не змішуйте процесори Intel і AMD. І навіть якщо все ЦПУ одного вендора, нові процесори будуть підтримувати додаткові інструкції не доступні на старих моделях. Зверніть увагу на Процесори, які ви купуєте.
Не планування svMotion (storage vMotion).
Снапшоти - зло, і ви НЕ повинні їх використовувати, крім як в рідкісних випадках. Переконайтеся, що ваші VMDK в presistent режимі або використовуйте RDM. Сервери повинні бачити вихідний і цільовий датастор, і кластер повинен мати достатньо ресурсів, щоб в момент перенесення мати дві одночасно запущені копії ВМ.
Мало вузлів в кластері.
Плануйте необхідні ресурси кластера і враховуйте необхідність резерву. Як правило, резерви по ресурсам на хостах повинні в сумі бути як один повноцінний сервер. Рішенням є використання політики admission control і планування виходу з ладу одного хоста.
Установка в резерв цілком одного хоста.
Не всі ВМ є критичними і у кожної є різний пріоритет перезапуску. Резервування за все виділеного хоста може бути нераціональним. Використовуйте для резерву відсоток ресурсів, який трохи менше, ніж внесок кожного хоста в повний кластер, щодо на сумарну кількість хостів. Наприклад, в чотирьох вузловому кластері, кожен сервер вносить 25%, в цьому випадку можна встановити відсоток резерву приблизно 20 або 15%.
Відсутність пріоритетів перезапуску VM.
Якщо ви використовуєте пропозицію з 4-го пункту, необхідно правильно налаштувати пріоритет перезапуску VM, оскільки ви не будете резервувати ресурси кластера для перезапуску ВСІХ ваших віртуальних машин. Встановіть звичайним ВМ низький пріоритет, а окремим ВМ підійміть пріоритет до середнього або високого в міру необхідності.
Відключення контролю за резервом (admission control).
Погана ідея! Ніколи, ніколи, ніколи не робіть цього! Увімкніть опцію - «do not power on if inadequate cluster resources»
Не зміна відсотка резервування ресурсів.
У міру додавання вузлів в кластер необхідно перерахувати відсоток резервування ресурсів, інакше система буде розбалансована.
Купівля різнорідних серверів.
Відмовостійкість повинна передбачати варіант відмови найбільшого сервера в кластері. Якщо є кластер з шести серверів з 96 ГБ оперативної пам'яті, і потім ви додаєте сервер з 384 ГБ оперативної пам'яті, будуть занадто розбалансовані розрахунки для резервування, і у вас залишиться багато невикористаних ресурсів.
Це заплутана тема для багатьох. До версії vSphere 5.0 в цьому налаштуванні можна було зробити помилки, які давали не зовсім очікувані результати. Можна на рівні хоста налаштувати відключення віртуальних машин при ізоляції, але на рівні кожної конкретної віртуальної машини змінити налаштування, якщо на ВМ є критичні програми, для яких потрібно переконатися, що їх відключення не є випадкова помилка. Починаючи з версії 5.0 до налаштування ізоляції хоста додалися хартбіти сховища, які використовуються тільки в разі, якщо мережа хоста недоступна. Сервери в кластері повинні мати принаймні одне загальне сховище.
Надмірне використання reservations, limits and affinities для ВМ.
Використовуйте shares замість reservations і обмежте використання affinities (або anti-affinities) правил. Ці обмеження можуть вплинути на продуктивність DRS. Будьте обережні при користуванні!
Робити обмеження по пам'яті.
Ніколи не робіть це, ніколи, ніколи! Обмежуйте використання пам'яті за допомогою додатків, якщо це можливо. Наприклад, ви можете налаштувати SQL, щоб обмежити обсяг пам'яті, який він буде використовувати всередині гостьової віртуальної машини.
Жодна людина не може обчислити значення всіх змінних і видати правильну відповідь. Нехай програмне забезпечення робить свою роботу.
Не розуміння правил DRS балансування.
Розрахунки по DRS Занадто складні
Міграція забирає ресурси, будь вони пропускною спроможністю мережі або процесорним часом. Не треба налаштовувати DRS для постійного міграції робочої навантаження між серверами. Необхідно налаштувати пороги, щоб зробити розумною міграцію, коли ресурси дійсно знаходяться поза балансом. vMotion було прикольним 5 років тому, але зараз немає необхідності постійно рухати ВМ просто для забави.
Занадто багато вузлів кластера.
Хоча технічно обмеження на кластер 32 вузла, але краще використовувати не більше 16-24. Чим більше хостів, тим більше розрахунків у DRS і все більше і більше споживання ресурсів.
Створення великих віртуальних машин.
Це нові значення в схемі ліцензування vSphere 5.0. Призначайте потрібну кількість пам'яті і віртуальних ЦП для ВМ. Не будьте занадто ліберальні. Робіть правильний розмір VM, що не збільшуйте їх ресурси без необхідності.