Как вы, возможно, знаете из документов , каждый тип узла сопоставляется с VMSS (набором масштабов виртуальной машины). VMSS - это набор узлов с одинаковой конфигурацией, поэтому каждый узел в VMSS будет иметь одинаковый объем ОЗУ, ЦП, ОС и конфигураций (порты, программное обеспечение и т. Д.), Если вы не зададите отдельные конфигурации для каждого узла после развертывается.
NodeType должен быть «существующим» типом узла в кластере. Мне интересно, почему это? Что означает «NodeTypeRef» в clustermanifest.json?
В SF NodeType - это виртуальное представление пула узлов (ВМ) с равными конфигурациями, которые могут обрабатывать тот же тип и объем работы, что и другие в том же пуле.
Они являются виртуальными, поскольку они представляют собой пул машин, он не привязан строго к VMSS, поскольку у вас не будет VMSS при запуске кластера OnPremises или других облачных провайдеров, но вы все равно можете иметь пул виртуальные машины той же конфигурации, связанные с NodeType.
Вашему кластеру рано или поздно придется масштабировать (увеличивать и уменьшать) количество узлов, а наличие NodeType облегчит размещение служб на новых узлах, потому что вы знаете, что определенные NodeTypes имеют предопределенные требования и любые новые узел, добавленный в пул, будет совместимым, поэтому вам не потребуется сложная конфигурация в конфигурации служб, чтобы ограничивать службы, запущенные на узлах, которые не поддерживаются.
Другой пример: если у вас не было NodeType, и вам необходимо назначить службу для определенного узла, в случаях, когда узел переходит в автономный режим, вы не сможете запустить службу, так как узел недоступен. , Тогда вы думаете, что я мог бы привязаться к конкретным требованиям, используя метки в узлах (то есть: Ram = 8 ГБ), но в случае, если вы хотите обновить эти виртуальные машины до 16 ГБ, вам также придется обновить службы, которые теперь должны быть совместимы с 16GB.
Примером является такой кластер:
FrontEndNodetype :
Вы будете устанавливать службы, необходимые для размещения вашего пользовательского интерфейса или API, вам не понадобятся огромные объемы диска, вам нужно настроить порты LoadBalancer, чтобы открыть доступ, например, к порту 80 (http)
BackEndNodeType :
Будут размещены рабочие сервисы, которые будут обрабатывать большую нагрузку, потребуется больше ресурсов процессора и памяти.
DBNodeType :
Будут размещать ваши базы данных, потребуется память и дисковое хранилище
Предполагая, что вы ограничите выполнение своих API-интерфейсов для FrontEndNodetype, если вы добавите туда новый узел, чтобы уменьшить нагрузку на другие узлы, SF будет знать, что он будет соответствовать требованиям сервиса и сможет без проблем запускать ваш API, потому что вы уже сказали во время развертывания, что FrontEndNodetype содержит все зависимости, в которых нуждается служба.
Другим примером может быть работа на основе графического процессора, поэтому для работы ваших служб потребуется очень специфическое оборудование.
.
На основании вашего примера:
Если вы создадите по одному типу узла для каждого добавляемого вами узла, вы потеряете преимущество наличия типов узлов и у вас не будет такой гибкости, как описано выше.
Другая проблема, когда вы добавляете несколько узлов с разными конфигурациями к одному и тому же типу узла, не будет проблемой для сервисной фабрики, но рано или поздно ваши службы начнут давать сбой на определенном узле, возможно, из-за неправильной конфигурации или если отсутствуют некоторые зависимости, будет сложно отладить и найти проблему, поскольку каждый узел будет иметь свою конфигурацию, вам потребуется некоторое время, чтобы определить, что проблемы возникают только в этом узле