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


Это канонический вопрос около планирование пропускной способности

Связанный:

У меня вопрос о планировании мощности. Сообщество сервера может помочь в следующем:


  • Какой сервер мне нужно обрабатывать? некоторое число пользователей?
  • Сколько пользователей может иметь сервер с некоторые спецификации ручка?
  • Будет некоторая конфигурация сервера быть достаточно быстрым для мой прецедент?
  • Я создаю сайт социальной сети: какое оборудование мне нужно?
  • Сколько полос частот мне нужно для некоторый проект?
  • Сколько пропускной способности будет некоторое число пользователей в некоторые приложения?

130
2018-04-30 19:20


Источник




Ответы:


Сообщество Server Fault, как правило, не может помочь вам в планировании емкости - лучший ответ, который мы можем предложить, - это «Контролируйте свой код на аппаратном уровне, аналогичном тому, что вы будете использовать в процессе производства, определите все узкие места, а затем определите, сколько рабочей нагрузки может обрабатывать ваше текущее оборудование, и / или сколько аппаратной мощности вам необходимо для обработки вашей целевой рабочей нагрузки»,


В области планирования потенциала существует ряд факторов, которые мы не можем адекватно оценить на сайте вопросов и ответов:

  • Требования вашего конкретного кода / программного обеспечения
  • Внешние ресурсы (базы данных, другое программное обеспечение / сайты / серверы)
  • Ваша рабочая нагрузка (пик, средняя, ​​очередь)
  • Бизнес-ценность эффективности (анализ затрат / выгод)
  • Ожидания в отношении производительности ваших пользователей
  • Любые соглашения об уровне обслуживания / договорные обязательства, которые у вас могут быть

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


Некоторые аксиомы планирования мощности

  1. ОЗУ дешево
    Если вы ожидаете, что ваше приложение будет использовать много оперативной памяти, вы должны разместить столько оперативной памяти, сколько сможете себе позволить.
  2. Диск дешевый
    Если вы планируете использовать много дисков, вы должны покупать большие диски - их много.
    Хранилище SAN / NAS дешевле, и обычно оно должно быть скорее крупным, чем небольшим, чтобы впоследствии избежать дорогостоящих обновлений.
  3. Рабочая нагрузка растет со временем
    Предположите, что ваши потребности в ресурсах будут увеличиваться.
    Имейте в виду, что увеличение может быть не симметричным (ЦП и ОЗУ могут расти быстрее, чем диск), и это может быть не линейным.
  4. Электричество дорого
    Несмотря на то, что оперативная память и диски значительно снизились в цене, стоимость электроэнергии неуклонно повышалась. Все эти дополнительные диски и оперативная память, не говоря уже о мощности процессора, увеличат ваш счет за электроэнергию (или счет, который вы платите своему провайдеру). Планируйте соответственно.

93
2018-01-17 15:46



Вы должны полностью отказаться от этого и использовать интеграцию по частям! - Gilles
+1. И оперативная память, как вы предлагаете в аксиоме №1, является одной из тех вещей, которая имеет огромные преимущества. Например, это увеличивает вашу способность лучше использовать кеширование, что, в свою очередь, позволяет делать меньше запросов к базе данных, что, в свою очередь, облегчает нагрузку на диск и центральный процессор. Меня часто разочаровывают хостинг-провайдеры, предлагающие быстрый процессор с их серверами и минимальное количество оперативной памяти. - Steve Wortham
Я бы добавил к этому: Диск вместимость дешево. диск представление становится дороже. Тем более, что мы наблюдаем рост размеров дисков более 10 лет, но законы физики не изменились. Используемое мной правило (на сегодняшний день, июнь 2014 года) заключается в том, что для оптимальной производительности: 75 IOP на шпиндель на SATA, 200 IOP на шпиндель на FC и 1500 IOP на SSD. Большие диски SATA обеспечивают очень низкое соотношение IO на гигабайт. - Sobrique


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

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

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

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

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


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

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

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

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

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


42
2018-02-06 20:32



прежде всего, использовать системы на основе vm на двух отдельных физических серверах с несвязанными vm. это позволяет сбой оборудования без потери всей системы. vm может перемещаться между идентичными серверами без потери данных. просто сеансы теряются, а затем перестраиваются. лично я бы передал на аутсорсинг хостинговой компании, предлагающей эти услуги (google или amazon). они дорогие, но намного меньше, чем их собственные. - Random-IT
То, что я чаще всего наблюдал в реализациях VM, - это дисковый ввод-вывод. Большинство людей понимают дисковое пространство, скорость процессора и память. Они забывают об этой производительности диска. - Dan Pritts


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

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

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

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

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


4