#networking #azure #azure-affinity-group
#сеть #azure #azure-affinity-group
Вопрос:
Теперь появилась новая функция региональных виртуальных сетей Azure, которая охватывает регион, есть ли преимущество в производительности при использовании групп привязки? В части часто задаваемых вопросов связанного сообщения в блоге говорится
Я подвергаюсь какому-либо снижению производительности для служб, работающих внутри региональной виртуальной сети?
Виртуальная сеть — это только логическая граница, она не определяет, куда на самом деле идут развертывания во виртуальной сети. Если по какой-то причине вам нужно, чтобы службы находились в одной и той же группе привязки, вы все равно можете сделать это внутри региональной виртуальной сети. Во время развертывания вам нужно будет указать группу привязки, к которой должна быть привязана размещенная служба. Единственным ограничением будет то, что группы привязки должны принадлежать к тому же региону, что и региональная виртуальная сеть.
Если вы не привязываете размещенную службу к группе привязки и развертываете службы непосредственно в региональной виртуальной сети, ваши развертывания будут размещены в единице масштаба внутри региона, к которому привязана виртуальная сеть.
У меня такое чувство, что рекомендация вообще больше не использовать группы привязки (основываясь на этом и некоторых других сообщениях, возможно, это мое понимание Azure и / или английского языка), но будут ли тогда службы и данные совместно расположены в центре обработки данных?
Ранее при создании виртуальной сети (виртуальной сети) требовалось связать виртуальную сеть с группой привязки, которая, в свою очередь, была связана с регионом. Это требование изменилось. Теперь виртуальные сети напрямую связаны с регионом (местоположением) на портале управления. Это дает вам больше свободы при создании ваших виртуальных сетей. При необходимости вы все равно можете связать свои облачные сервисы с группами привязки, но это не обязательно.
Регион представляет, где будет наложение виртуальной сети. Все, что вы развертываете в виртуальной сети, будет физически размещено в регионе. Если вы хотите дополнительно указать, что вы хотите, чтобы ваши ресурсы физически находились в непосредственной близости друг от друга в пределах одного региона, вы можете указать группу привязки для этих конкретных ресурсов. Это означало бы, что эти ресурсы не только находятся в одном и том же физическом местоположении, но и находятся очень близко друг к другу в центре обработки данных.
Итак, я полагаю, что при использовании групп привязки есть преимущество в производительности.
Группа привязки служит двум целям:
- совместное использование облачной службы и учетной записи хранилища
- хост для виртуальной сети группы привязки
Второй из них теперь устарел. Первое все еще возможно, но не было подчеркнуто как оптимизация задержки, которая была до обновления сети Azure в 2012 году. Фактически стандартный способ развертывания виртуальной машины на портале Azure не поддерживает одновременное создание облачной службы в группе привязки и региональной виртуальной сети. Это сбивает с толку людей, которые пытаются соответствовать современной передовой практике использования региональной виртуальной сети для развертывания и исторической передовой практике создания облачного сервиса в группе привязки.
На данный момент, похоже, нет особых причин для развертывания облачной службы в группе привязки. Однако, как и в случае с другими вариантами развертывания, людям может быть разумно протестировать это для своих конкретных рабочих нагрузок.
Ответ №1:
Никогда не было окончательно доказано, что использование групп привязки повышает производительность / задержку. Сообщения о таких преимуществах (или их отсутствии) сильно различаются и в основном носят эпизодический характер.
Ответ №2:
См. Также исходный вопрос. Наиболее точный источник небольшого преимущества в производительности и вариантов использования для групп привязки, которые я могу найти, можно найти в Convective blog post Affinity Groups в Azure .
Группа привязки служит двум целям:
- совместное использование облачной службы и учетной записи хранилища
- хост для виртуальной сети группы привязки
Второй из них теперь устарел. Первое все еще возможно, но не было подчеркнуто как оптимизация задержки, которая была до обновления сети Azure в 2012 году. Фактически стандартный способ развертывания виртуальной машины на портале Azure не поддерживает одновременное создание облачной службы в группе привязки и региональной виртуальной сети. Это сбивает с толку людей, которые пытаются соответствовать современной передовой практике использования региональной виртуальной сети для развертывания и исторической передовой практике создания облачного сервиса в группе привязки.
На данный момент, похоже, нет особых причин для развертывания облачной службы в группе привязки. Однако, как и в случае с другими вариантами развертывания, людям может быть разумно протестировать это для своих конкретных рабочих нагрузок.