2017-01-27 5 views
2

Я заметил, что при развертывании службы stateless для кластера максимальное количество экземпляров не может превышать число физических узлов. Два вопроса:Развертывание числа служб без состояния больше, чем количество узлов кластера

  1. Это жесткий предел по дизайну (т. Е. Не только проблема с кластером dev)?
  2. Что происходит с способностью обработки этой услуги, когда половина кластера отключена?

ответ

3

Количество экземпляров не может превышать количество узлов в кластере, нет, есть placement constraint, что гарантирует это. Вы можете изменить ограничения размещения для своего кластера, но я не думаю, что вы можете установить его полностью игнорировать ограничение ReplicaExclusionStatic. Также стоит отметить, что в настройке по умолчанию оно рассматривается как предупреждение, то есть если у вас есть node count = 7, а ваш кластер имеет 5 узлов, это даст вам предупреждение о том, что он не может разместить 2 экземпляра.

В Service Fabric есть и понятие экземпляра и раздела и наиболее часто экземпляр ассоциируется с лицами без услуг, а также раздел с Stateful, но это вовсе не означает, что вы не можете иметь разделы апатридов услуг (но в большинстве случаев это может и не иметь смысла).

Если вы хотите иметь больше фактических экземпляров вашей службы, вы можете изменить количество разделов, чтобы создавать дополнительные разделы на каждом узле. По умолчанию для Stateless службы SingletonPartition и счетчик экземпляра -1, что ставит один экземпляр на каждом доступном узле:

В ApplicationManifest.xml:

<Service Name="MyService"> 
    <StatelessService ServiceTypeName="MyServiceType" InstanceCount="[MyService_InstanceCount]"> 
     <SingletonPartition /> 
    </StatelessService> 
</Service> 

И в ваших PublishProfiles/Cloud.xml:

<Parameters> 
    <Parameter Name="MyService_InstanceCount" Value="-1" /> 
</Parameters> 

На кластере из 5 узлов вы получите 5 экземпляров, ничего странного. Если вы перейдете к экземпляру count = 6, вы получите предупреждение о размещении (и все еще не более 5 фактических экземпляров).

Теперь, если вы хотите иметь больше экземпляров (или копии), работающие на каждом узле можно изменить количество раздела вашего Stateless службы:

<Service Name="MyService"> 
    <StatelessService ServiceTypeName="MyServiceType" InstanceCount="[MyService_InstanceCount]"> 
     <UniformInt64Partition PartitionCount="4" LowKey="0" HighKey="4" /> 
    </StatelessService> 
</Service> 

На том же кластере и с тем же экземпляром посчитайте, что вместо этого вы получите 20 (5 узлов x 4 раздела) реплик вашей службы.

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

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

В этой статье обсуждаются вопросы о разметке, экземплярах и репликах. https://blogs.msdn.microsoft.com/mvpawardprogram/2015/10/13/understanding-service-fabric-partitions/

+0

спасибо. Поэтому, если количество разделов в кластере опущено, а половина кластера опущена, соответственно будет затронута возможность обработки системной службы. Частный SF-кластер может быстро восстановить эти узлы. –

+0

Я думаю, что понимание * актуальной * вычислительной мощности вашего кластера может быть трудно определить теоретически, это зависит от того, какие типы узлов у вас есть (нет процессоров и т. Д.) И как работает ваш код в службах. В некоторых случаях наличие нескольких реплик каждой службы на каждом узле может означать, что вы можете иметь более высокую пропускную способность, но в других случаях это необязательно может означать это. Если ваш служебный код обрабатывает асинхронную обработку запросов в хорошем смысле, один экземпляр может очень хорошо обрабатывать столько запросов в параллели. – yoape

+0

Спасибо, помощник, много помогли. Одна вещь, которую я имею в виду: почему они решили, что службы без состояния не могут иметь несколько экземпляров, работающих в одном узле? Не имеет никакого смысла, поскольку мы без страха, вероятно, не беспокоимся о потере данных, если узел опускается. Он должен иметь лучшую обработку для этого, если количество экземпляров больше, чем количество узлов. –