Service Fabric Networking. Можно ли иметь два узла разных типов узлов на одной виртуальной машине?
Я спрашиваю это в связи с моим предыдущим постом. Я немного читал, но не увидел четкого ответа на мой комментарий. Ответ Диего.
Service Fabric - Как зарезервировать или защитить мой порт в жестком коде
ОБНОВЛЕНИЕ: Поскольку я заканчиваю это, я думаю, что вопрос действительно становится, можете ли вы иметь несколько узлов на одной ВМ. Дело не в типах узлов, а в самих узлах. Поэтому возникает вопрос: могу ли я иметь виртуальную машину с несколькими IP-адресами, на которой размещается Service Fabric, а затем размещать на ней два узла разных типов?
Таким образом, я мог бы решить вышеуказанную проблему и иметь тип узла для внешнего доступа и второй тип узла для внутреннего доступа вместо жесткого кодирования порта, выходящего за пределы диапазона, используемого при настройке кластера.
Думаю, я стану жадным и задам следующий вопрос:
Если я не могу иметь несколько IP-адресов, есть ли что-то, о чем следует беспокоиться, используя порт за пределами диапазона. Будет ли служба Fabric использовать этот номер порта для чего-либо еще?
Например, я бы не хотел, чтобы Service Fabric не думала, что микро-сервис должен управляться так же, как и все другие микро-сервисы, только потому, что порт находится вне диапазона?
Например, в моем файле onPrem ClusterConfig. Windows.MultiMachine.json у меня есть:
"nodes": [
{
"nodeName": "vm0",
"iPAddress": "Server1.DomainName.net",
"nodeTypeRef": "NodeType0",
"faultDomain": "fd:/dc1/r0",
"upgradeDomain": "UD0"
},
{
"nodeName": "vm1",
"iPAddress": "Server2.DomainName.net",
"nodeTypeRef": "NodeType0",
"faultDomain": "fd:/dc1/r1",
"upgradeDomain": "UD1"
},
{
"nodeName": "vm2",
"iPAddress": "Server3.DomainName.net",
"nodeTypeRef": "NodeType0",
"faultDomain": "fd:/dc1/r2",
"upgradeDomain": "UD2"
}
]
"nodeTypes": [
{
"name": "NodeType0",
"clientConnectionEndpointPort": "19000",
"clusterConnectionEndpointPort": "19001",
"leaseDriverEndpointPort": "19002",
"serviceConnectionEndpointPort": "19003",
"httpGatewayEndpointPort": "19080",
"reverseProxyEndpointPort": "19081",
"applicationPorts": {
"startPort": "20001",
"endPort": "20100"
},
"isPrimary": true
}
],
Могу ли я вместо этого сделать что-то вроде этого, где IP 1 и 4, 2 и 5 и 3 и 6 находятся на одной виртуальной машине? Обратите внимание, что начальный и конечный порты для двух типов узлов не разделены, чтобы обеспечить жестко закодированные конечные точки WebAPI.
"nodes": [
{
"nodeName": "vm0",
"iPAddress": "IPAddress_1",
"nodeTypeRef": "NodeType0",
"faultDomain": "fd:/dc1/r0",
"upgradeDomain": "UD0"
},
{
"nodeName": "vm1",
"iPAddress": "IPAddress_2",
"nodeTypeRef": "NodeType0",
"faultDomain": "fd:/dc1/r1",
"upgradeDomain": "UD1"
},
{
"nodeName": "vm2",
"iPAddress": "IPAddress_3",
"nodeTypeRef": "NodeType0",
"faultDomain": "fd:/dc1/r2",
"upgradeDomain": "UD2"
}
]
"nodes": [
{
"nodeName": "vm3",
"iPAddress": "IPAddress_4",
"nodeTypeRef": "NodeType1",
"faultDomain": "fd:/dc1/r0",
"upgradeDomain": "UD0"
},
{
"nodeName": "vm4",
"iPAddress": "IPAddress_5",
"nodeTypeRef": "NodeType1",
"faultDomain": "fd:/dc1/r1",
"upgradeDomain": "UD1"
},
{
"nodeName": "vm5",
"iPAddress": "IPAddress_6",
"nodeTypeRef": "NodeType1",
"faultDomain": "fd:/dc1/r2",
"upgradeDomain": "UD2"
}
]
"nodeTypes": [
{
"name": "NodeType0",
"clientConnectionEndpointPort": "19000",
"clusterConnectionEndpointPort": "19001",
"leaseDriverEndpointPort": "19002",
"serviceConnectionEndpointPort": "19003",
"httpGatewayEndpointPort": "19080",
"reverseProxyEndpointPort": "19081",
"applicationPorts": {
"startPort": "20001",
"endPort": "20500"
},
"isPrimary": true
}
"name": "NodeType1",
"clientConnectionEndpointPort": "19000",
"clusterConnectionEndpointPort": "19001",
"leaseDriverEndpointPort": "19002",
"serviceConnectionEndpointPort": "19003",
"httpGatewayEndpointPort": "19080",
"reverseProxyEndpointPort": "19081",
"applicationPorts": {
"startPort": "20501",
"endPort": "21000"
},
],
Заранее спасибо Грег
3 ответа
Как отмечено в шагах по подготовке к автономному развертыванию, у вас не может быть двух узлов на одной виртуальной машине.
"Однако в производственной среде Service Fabric поддерживает только один узел для каждой физической или виртуальной машины".
И да и нет.
Когда вы устанавливаете кластер SF на компьютере разработчика, он имитирует кластер из 5 узлов на том же компьютере, по умолчанию вы не можете сделать это при подготовке с портала Azure. Service Fabric - это не что иное, как службы Windows, работающие поверх виртуальных машин.
Вопрос здесь должен быть:
Если у меня есть два типа узлов на одном компьютере, это решит проблему конфликта портов?
Ответ отрицательный, потому что они оба будут конкурировать за порты так же, как и при попытке загрузить одну службу, привязанную к порту 80, на всех узлах вашего локального компьютера разработки.
Как я предположил в другом вопросе, если создание типов узлов не является вариантом, вы должны использовать жестко закодированные порты вне списка портов приложения.
Например: - ServiceA - это API, который предоставляет операции для порта 80 - ServiceB - это фоновая рабочая служба, которая использует случайный порт (взятый из диапазона портов приложения)
Проектируя свой сервис таким образом, у вас не будет проблем с портами.
Другой вариант позволит всем службам использовать произвольные порты и обратный прокси-сервер для связи с ними, проверьте это здесь.
В общем, вы сохраняете общедоступную службу (т.е. основной API Asp.net), которая будет использоваться внешними клиентами (всеми, кто получает доступ извне кластера sf). Этот API-интерфейс используется для вызова других микро-служб, размещенных в том же кластере. Вы можете использовать удаленное взаимодействие в качестве стека связи в кластере. Таким образом, вам не нужно беспокоиться о портах в кластере.
Единственный порт, который необходим, это 80 или какой-то другой порт для внешнего клиента, который прослушивает служба API. Это предпочтительный способ в соответствии с документацией.