Джон Сэвилл отвечает на наши вопросы по Azure. Часть III

Я использую общий виртуальный диск Shared VHDX в кластере Hyper-V и обратил внимание на увеличенный сетевой трафик между узлами в кластере. Почему это происходит?
Общие тома кластера Cluster Shared Volumes (CSV) были вновь введены в Windows Server 2008 R2. Они разрешают доступ к LUN всем узлам в кластере, одновременно допуская прямые операции ввода-вывода данных со всех узлов, тогда как изменения любых метаданных выполняются узлом-координатором для конкретного тома CSV. Запросы метаданных отсылаются по сети кластера на узел-координатор. Узлы могут потерять прямой доступ к хранилищу данных, но тогда они переходят в режим перенаправления и отсылают все операции ввода-вывода по сети кластера на узел-координатор. Таким образом, продолжается чтение и запись данных.

Общий виртуальный диск Shared VHDX позволяет нескольким виртуальным машинам использовать один и тот же файл VHDX на нескольких узлах. Таким образом, необходимо управлять общим доступом.

Как это происходит? Узел-координатор отсылает все операции ввода-вывода на общий VHDX. Тот, в свою очередь, требует от всех узлов, которые являются хостами виртуальных машин и не являются узлами-координаторами, отсылки своих операций ввода-вывода на узел-координатор.

Например, если система хранения данных располагается на масштабируемом сервере Scale-out File Server (SoFS), доступ к которому осуществляется по SMB 3, тогда все узлы будут перенаправлены на узел-координатор в SoFS для заданного совместно используемого ресурса, который является хостом общего диска Shared VHDX. Если у сервера есть соединение с SAN со скоростью 8 Гбит/с и соединение с другими узлами со скоростью в 1 Гбит/с по сети кластера, то это повлияет на производительность системы хранения данных. Вы непременно заметите увеличенный трафик по сети кластера.


Когда используется общий диск Shared VHDX, даже если узлы в кластере имеют прямое подсоединение к системе хранения данных, которая является хостом для Shared VHDX, реальная операция ввода-вывода отсылается по сети кластера, чтобы ее выполнил координатор. Таким образом, очень важно внимательно отнестись к созданию схемы организации сети в кластере, когда вы используете Shared VHDX.


Обратите внимание, что это применимо только к трафику для Shared VHDX, остальной трафик ввода-вывода отсылается прямо в систему хранения данных. Достаточно много полезной информации вы можете найти в следующих материалах:
• Details on how Cluster Shared Volumes work (http://blogs.msdn.com/b/clustering/archive/2013/12/02/10473247.aspx);
• Specific changes to the workings of Shared VHDX (http://blogs.technet.eom/b/askpfeplat/archive/2015/06/01/how-shared-vhdx-works-on-server-2012-r2.aspx).

Если распределение виртуальной машины в Azure отменено, плачу ли я за систему хранения данных, которую она использует?
Да. Даже если виртуальная машина больше не распределена на хосте в Azure, физическая система хранения данных для виртуальной машины все еще существует в учетной записи системы хранения данных Azure. Это означает, что вы все еще платите за систему хранения данных для диска операционной системы и за любые диски данных.

Как мне назначить тип сети в Windows, используя PowerShell?
Windows подразделяет сети на три типа: общедоступная сеть, частная внутренняя сеть и сеть домена. Это позволяет выбирать различные настройки сетевых экранов, базируясь на типе сети. Е1апример, самая ограниченная схема настройки — для общедоступных сетей, а наименее ограниченная — для сетей домена. По умолчанию любое новое сетевое соединение становится частным внутренним соединением, а если службы Active Directory обнаруживаются в сети, ее тип автоматически изменяется на сеть домена. Если вам нужно заставить сеть иметь иной профиль, самый распространенный способ изменения общедоступной сети на частную внутреннюю сеть — это использование PowerShell.

Давайте сначала рассмотрим профиль, используемый сетевыми адаптерами:

Найдите Interface!ndex — номер адаптера, который вы хотите изменить, а затем используйте команду:

Например:


Как мне задать параметры нескольких серверов Web Application Proxy, чтобы опубликовать те же самые приложения в резервной среде?
Компонент Web Application Proxy (WAP), который составляет часть Windows Server 2012 R2, использует обобщенную схему настроек, которая является частью развертывания федеративной службы каталогов ADFS, к которой этот компонент подсоединен. Следовательно, если несколько серверов WAP используют одну и ту же среду ADFS, то они будут иметь те же самые опубликованные приложения и службы. Никаких других действий не требуется.


Если вам нужны глобальные возможности, такие как переход на другой ресурс при сбое в работе с одного местоположения опубликованных приложений на другое, то вам нужен парный WAP с глобальной службой DNS для решения проблемы, с учетом географического положения, например менеджер трафика Azure Traffic Manager. В таком сценарии WAP в нескольких местоположениях будет публиковать те же самые службы, но пользователи будут перенаправляться на экземпляр WAP, который находится к ним ближе всего, с помощью компонента балансировки нагрузки Performance в менеджере Traffic Manager.