В большинстве мест, где вы читаете о планировании кластера, они предполагают, что этот предмет - отчасти наука, а отчасти искусство, потому что на этот вопрос нет простого ответа.Трудно ответить на него, потому что это во многом зависит от сложности вашего приложения, и, не зная внутренних органов о том, как оно работает, мы можем только угадать решение.
На основании ваших вопросов лучшее руководство, которое я могу дать вам, этоMeasure first, Measure again, Measure... Plan later.Ваше приложение может быть интенсивно использующим память, сеть, процессор, диск и сын, единственный способ найти лучшую конфигурацию - это когда вы ее понимаете.
Чтобы понять ваше приложение до того, как вы примете решение о структуре SF, вы можете просто развернуть простой кластер с несколькими типами узлов, содержащий один узел каждого размера виртуальной машины, и измерить поведение вашего приложения на каждом из них, а затем выдобавит больше узлов и охватит несколько экземпляров вашего сервиса на этих узлах и увидит, какая конфигурация лучше всего подходит для каждого сервиса.
1. Сколько типов узлов?
Мне нравится отображать типы узлов как 1: 1 для ролей в вашем приложении, но это не закон, это будет зависетьсколько ресурсов потребляет каждая служба, если служба потребляет достаточно ресурсов, чтобы одна виртуальная машина (узел) была занята (память, процессор, диск, ввод-вывод), это хороший вариант, чтобы иметь собственный тип узла, в других случаяхОблегченные службы, которые были бы бесполезной тратой ресурсов на выделение всей виртуальной машины (узла), например, запланированные задания, резервное копирование и т. д. В этом случае вы могли бы предоставить набор машин, которые можно было бы использовать совместно.для этих служб важно помнить одну важную вещь при совместном использовании типа узла для нескольких служб: они будут конкурировать за ресурсы (память, ЦП, сеть, диск) и показатели производительности, которые вы приняли для каждой службы в отдельности.может больше не совпадать, поэтому им потребуется больше ресурсов, можно проверить их вместе.
Другой момент - это числоРеплики, наличие одного экземпляра вашей службы ненадежно, поэтому вам придется создавать его реплики (правильное число, которое я опишу в следующем ответе), в этом случае вы получите нагрузку службы, разделенную на несколько узлов,сделав этот тип узла недоиспользуемым, вы могли бы рассмотреть возможность присоединения сервисов к одному и тому же типу узла.
2. Сколько узлов на тип узла?
Как указывалось ранее, это будет зависеть от потребления ресурсов вашей службы, но самое основное правило - минимум 3 для каждого типа узла.
Почему 3?
Поскольку 3 - это наименьшее число, где вы можете иметь скользящее обновление и гарантировать кворум в 51% работающих узлов \ service \ instances.
- 1 Узел : Если у вас есть служба, выполняющая 1 экземпляр на узле типа 1, при развертывании новой версии службы вам придется отключить этот экземпляр, прежде чем появится новая,поэтому у вас не будет экземпляра для обслуживания нагрузки при обновлении.
- 2 узла : аналогично 1 узлу, но в этом случае вы продолжаете работать только 1 узлув случае сбоя у вас не будет аварийного переключения для обработки нагрузки до тех пор, пока не будет запущен новый экземпляр, будет хуже, если вы используете службу с сохранением состояния, потому что у вас будет только одна копия ваших данных во время обновления ив случае неудачи вы можете потерять даta.
- 3 узла : во время обновления у вас по-прежнему есть 2 доступных узла, когда один из обновленных возвращается, другой отключается, и вы по-прежнемуесли 2 узла работают, в случае отказа одного узла другой узел может поддерживать нагрузку до развертывания нового узла.
3 узла не означает, что ваш кластер будет высоконадежным, это означает, что вероятность сбоя и потери данных будет ниже, возможно, вам не повезло потерять 2 узла одновременно.Как указано в документах , в производственной среде лучше всегда сохранять количество узлов равным 5 или более и планировать иметь кворум в 51% узлов / служб.В этом случае я бы порекомендовал 5, 7 или 9 узлов в тех случаях, когда вам действительно нужно увеличить время безотказной работы 99,9999 ...%
3. Какой размер виртуальной машины мне нужно выбрать??
Как было сказано ранее, ответом будут только измерения.
Наблюдения:
Эти рекомендации не учитываютПринимая во внимание планирование для основных типов узлов, рекомендуется иметь как минимум 5 узлов на основных типах узлов, именно там размещаются системные службы SF, они отвечают за управление кластером, поэтому они должны быть высоконадежными, иначе вы рискуете потерятьконтроль вашего кластера.Если вы планируете использовать эти узлы совместно со службами приложений, имейте в виду, что ваши службы могут влиять на них, поэтому вы всегда должны следить за ними, чтобы проверить, какое влияние это может вызвать.