Чи можете ви допомогти мені в плануванні своїх можливостей?

Це канонічне питання щодо планування потужностей

Пов'язані:

• Як ви робите тестування завантаження та планування потужностей для веб-сайтів?
• Як ви робите тестування навантаження та планування потужностей для баз даних?

У мене питання щодо планування потужностей. Чи може спільнота серверних помилок допомогти у наступному:

• Який сервер мені потрібен для обробки певної кількості користувачів?
• Скільки користувачів може обробляти сервер із деякими специфікаціями ?
• Чи буде якась конфігурація сервера достатньо швидкою для мого випадку використання ?
• Я будую веб-сайт у соціальних мережах: яке обладнання мені потрібно?
• Скільки пропускної здатності мені потрібно для певного проекту ?
• Яку пропускну здатність буде використовувати деяка кількість користувачів у якійсь програмі ?

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

У плануванні потенціалу грає низка факторів, які ми не можемо адекватно оцінити на веб-сайті із запитаннями та відповідями:

• Вимоги вашого конкретного коду / програмного забезпечення
• Зовнішні ресурси (бази даних, інше програмне забезпечення / сайти / сервери)
• Ваша навантаження (пік, середнє значення, черга)
• Вартість діяльності (аналіз витрат / вигод)
• Очікування ефективності ваших користувачів
• Будь-які договори про рівень обслуговування / договірні зобов'язання, які ви можете мати

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

Деякі аксіоми планування ємності

1. Оперативна пам’ять дешева
   Якщо ви очікуєте, що ваша програма використовує багато оперативної пам’яті, вам слід ввести стільки оперативної пам’яті, скільки ви можете собі дозволити / помістити.
2. Диск дешевий
   Якщо ви плануєте використовувати багато диска, вам слід придбати великі диски - їх багато.
   Зберігання SAN / NAS дешевше, і зазвичай має бути спеціально великим, а не малим, щоб уникнути дорогих оновлень пізніше.
3. З часом зростає навантаження.
   Припустимо, що ваші потреби в ресурсах будуть збільшуватися.
   Майте на увазі, що збільшення може бути несиметричним (процесор і оперативна пам’ять можуть підніматися швидше, ніж диск), і вони можуть бути не лінійними.
4. Електроенергія дорога
   Навіть незважаючи на те, що оперативна пам’ять та диски значно подешевшали, вартість електроенергії постійно зростала. Усі ці додаткові диски та оперативна пам’ять, не кажучи вже про потужність процесора, збільшать ваш рахунок за електроенергію (або рахунок, який ви платите своєму провайдеру). Плануйте відповідно.

Планування кількості віртуальної машини

Що стосується того, щоб з'ясувати, скільки віртуальних машин слід запланувати на одному хості, насправді не існує справді хороших правил. Насправді є лише одне, і це лише добрий вид:

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

Що не дуже корисно. Якщо в цих віртуальних машинах будуть запущені програми з низьким процесором, то ваш обмежувач буде заснований на оперативній пам'яті. Кожна платформа VM має власні можливості для передплати оперативної пам’яті, тому це не так просто, як TOTAL_RAM / Per-VM-RAM = MachineCount, але це число є хорошим пунктом планування.

Але що робити, якщо ваші відеомагнітофони займаються, окрім низького рівня процесора?

Кількість віртуальної машини обмежена семи дискретними ресурсами, доступними для хост-машини:

• Hypervisor VMware, Xen, HyperV, KVM, що завгодно. У кожного є свої особливості, що впливають на кількість. Одні дуже добре сприймають депулікацію сторінки пам'яті, інші - не дуже. Деякі не дозволяють переплатити ємність процесора, деякі -.
• Основна швидкість процесора Це обмежує максимальну однопоточну продуктивність, яку VM зможе запустити. 36 ядер процесора 1,8 ГГц можуть бути 64,8 ГГц процесора на хості, але жоден потік не працюватиме швидше, ніж 1,8 ГГц.
• Кількість процесорних ядер Ця швидкість з основним процесором описує максимальну продуктивність процесора, яку ви можете зазнати.
• Системна оперативна пам’ять Як описано вище, це обмежує кількість VM, які ви можете запустити. Деякі гіпервізори кращі за інших у таких речах, як дедуплікація сторінки пам’яті, тому якщо ви працюєте з 100 однаковими віртуальними машинами, ви можете запакувати набагато більше таких систем у таких дедупликаційних системах, ніж якщо б у вас було 100 абсолютно різних віртуальних машин.
• Розмір диска Кожне зображення ОС займає певну кількість місця. Вам потрібно достатньо місця, щоб усе це зберігати. Тому розмір диска встановлює верхню межу кількості візменів, на яких ви можете розмістити.
• Пропускна здатність вводу / виводу Диск, що лежить в основі відеомагнітофонів, має максимум, скільки вводу / виводу за секунду він може працювати. Якщо ви кинете на нього занадто багато, системи завалиться в очікуванні завершення вводу / виводу. Це ставить верхню межу щодо того, скільки ВМ / споживаючих VM ви можете запустити.
• Пропускна здатність мережі Для мереж, що використовують мережу, доступна пропускна здатність мережі встановить межу, скільки таких віртуальних машин можна запустити на даному хості.

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

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

Щоб зрозуміти, скільки віртуальних машин можна запакувати в хост-систему, вам потрібно знати, як працюють ваші системи і для чого вони потрібні, щоб добре працювати. Коли ви це знаєте, то можете робити планування підрахунку. А ще краще, з’ясуйте, наскільки непоганий для створення ваших хост-систем!

Переконайтеся, що ви ставите правильне запитання.

• Комп'ютери дешеві
• Майбутні потреби дуже важко передбачити
• Плануйте, як масштабувати, а не що купувати достроково

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

Переконайтеся, що ви маєте уявлення про те, як ви збираєтеся масштабувати, коли речі стають більшими. Чи можете ви додати більше серверів за балансиром навантаження? Чи можете ви відтінити сервер Redis?

Також, власний центр обробки даних смокче. Центр обробки даних (навіть якщо це лише один комп'ютер) - це відволікання від вашої фактичної мети. Не можна просто придбати комп’ютер, увімкнути його і піти пішки. Вам потрібні кондиціонер, фільтрація повітря, надійне живлення, надійний Інтернет, резервні копії, запасні частини, фізична кімната для зростання, потужність для нарощування потужності, силові кабелі, які не спрацьовують, і мільйон інших головних болів.