Можете ли вы помочь мне с моим планированием мощности?

Планирование количества виртуальных машин

Когда дело доходит до определения количества виртуальных машин, которые вы должны запланировать на одном хосте, на самом деле не существует хороших практических правил. На самом деле, есть только один, и это только отчасти хорошо

Количество виртуальных машин обычно ограничено оперативной памятью, за исключением случаев, когда это не так.

Что не очень полезно. Если эти виртуальные машины будут работать с приложениями с низким ЦП, тогда ваш ограничитель будет основан на ОЗУ. Каждая платформа VM имеет свои собственные возможности для переподписки ОЗУ, поэтому это не так просто, как TOTAL_RAM / Per-VM-RAM = MachineCount, но это число является хорошим элементом планирования.

Но что, если ваши виртуальные машины делают что-то еще помимо низкопроцессорной пакетной обработки?

Количество виртуальных машин ограничено семью дискретными ресурсами, доступными хост-машине:

• Гипервизор VMware, Xen, HyperV, KVM, что угодно. Каждый из них имеет свои особенности, влияющие на счет. Некоторые очень хороши в дедупликации страниц памяти, другие не так уж и хороши. Некоторые не допускают переподписку процессорной мощности, некоторые делают.
• Скорость ядра процессора. Это ограничивает максимальную однопоточную производительность, которую может работать ВМ. 36 ядер процессора с частотой 1,8 ГГц могут иметь частоту процессора 64,8 ГГц на хосте, но ни один из потоков не будет работать быстрее, чем 1,8 ГГц.
• Число ядер ЦП Это, с частотой ядра, описывает предел максимальной производительности ЦП, которую вы можете испытать.
• ОЗУ системы Как описано выше, это ограничивает количество виртуальных машин, которые вы можете запустить. Некоторые гипервизоры лучше, чем другие, в таких вещах, как дедупликация страниц памяти, поэтому, если вы используете 100 идентичных виртуальных машин, вы можете упаковать гораздо больше таких в таких дедуплицирующих системах, чем если бы вы использовали 100 совершенно разных виртуальных машин.
• Размер диска Каждый образ ОС занимает определенное количество места. Вам нужно достаточно места, чтобы хранить все это. Следовательно, размер диска устанавливает верхний предел количества виртуальных машин, которые вы можете разместить.
• Пропускная способность ввода / вывода Диск, лежащий в основе виртуальных машин, имеет максимальное количество операций ввода-вывода в секунду, которые он может обрабатывать. Если вы добавите слишком много к нему, системы будут зависать в ожидании завершения ввода-вывода. Это накладывает верхний предел на количество ВМ, потребляющих ввод / вывод, которые вы можете запустить.
• Пропускная способность сети Для виртуальных машин, использующих сеть, доступная пропускная способность сети будет устанавливать предел для количества таких виртуальных машин, которые вы можете запустить на данном хосте.

Все это может быть тем, над чем вы спотыкаетесь, все зависит от того, что вы делаете со своими виртуальными машинами. Некоторые вещи, которые нужно помнить:

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

Чтобы выяснить, сколько виртуальных машин вы можете упаковать в хост-систему, вам нужно знать, как работают ваши системы и что им нужно для нормальной работы. Как только вы это узнаете, вы сможете планировать счет. А еще лучше выяснить, насколько сложным вам нужно сделать свои хост-системы!

Убедитесь, что вы задаете правильный вопрос.

• Компьютеры дешевы
• Будущие потребности очень сложно предсказать
• Планируйте, как масштабировать, а не что покупать заранее

Если вы не знаете, что вам нужно, это означает, что вам не нужно много. Если у вас есть горячий веб-сайт, у вас, вероятно, также есть рабочая группа, которая знает, сколько оперативной памяти, диска, io, сети и т. Д. Требуется вашему приложению. Если вы находитесь в стадии сна, вам следует начать с рабочего стола и идти вверх.

Убедитесь, что у вас есть представление о том, как вы будете масштабироваться, когда все станет больше. Можете ли вы добавить больше серверов за балансировщиком нагрузки? Можете ли вы осквернить сервер Redis?

Кроме того, иметь свой собственный дата-центр - отстой. Центр обработки данных (даже если это всего лишь один компьютер) отвлекает от вашей реальной цели. Вы не можете просто купить компьютер, включить его и уйти. Вам нужны кондиционер, фильтрация воздуха, надежное электропитание, надежный интернет, резервные копии, запасные части, физическое пространство для роста, мощность для наращивания, силовые кабели, которые не сработали, и еще миллионы других головных болей.

Начните с оценки количества запросов в секунду. 100 т.е. прост в обращении. 1000 может быть проблемой. 1 миллион практически невозможен на одной машине.

«Количество пользователей». Тысячи пользователей, ничего не делающих, — это меньше проблем, чем один пользователь, предсказывающий погоду на завтра.

«Пропускная способность» — сколько байт нужно передать на сервер или из него? Сколько данных будет у вас на диске?

«Социальные сети». Создайте прототип, привлеките тысячу пользователей и соберите показатели. Затем давайте обсудим, как следует переписать схему и перепроектировать топологию сервера.

«Шардинг», «Кэширование» и т. д. Когда вы доберетесь до миллиона «пользователей», вам может потребоваться разделение данных и активности между сотней серверов. Без более подробной информации мы не можем обсуждать, как выполнить разделение. Кроме того, действительно преждевременно проектировать масштабные проекты, пока вы не поймете, в какие кирпичные стены вы собираетесь удариться.