Настройка round robin dns exchange
I have setup an Exchange 2016 DAG but now i need to sort the DNS, can someone point me to a decent guide for setting up Round Robin internally and externally using a domain hosting company?
Load balancing options in Exchange Server
In the example shown here, multiple servers configured in a database availability group (DAG) host the Mailbox servers running Client Access services. This provides high availability with a small Exchange server footprint. The client connects to the load balancer rather than directly to the Exchange servers. There's no requirement for load balancer pairs, however we recommend deploying in clusters to improve network resilience.
Be aware that DAGs use Microsoft Clustering Services. These services can't be enabled on the same server as Windows Network Load Balancing (NLB). Accordingly, Windows NLB is not an option when using DAGs. There are third-party software and virtual appliance solutions in this case.
Simplicity comes at a price, however, in this case, DNS round robin isn't truly load-balancing the traffic, because there isn't a way programmatically to make sure that each server gets a fair share of the traffic. Also, there is no service level monitoring so that when a single service fails, clients aren't automatically redirected to an available service. For example, if Outlook on the web is in failure mode, the clients see an error page.
DNS load balancing requires more external IP addresses when you publish externally. That means that each individual Exchange server in your organization would require an external IP address.
There are more elegant solutions to load balancing your traffic, such as hardware that uses Transport Layer 4 or Application Layer 7 to help distribute client traffic. Load balancers monitor each Exchange client-facing service, and if there is a service failure, load balancers can direct traffic to another server and take the problem server offline. Additionally, some level of load distribution makes sure that no single Mailbox server is proxying the majority of client access.
Load balancing services can use Layer 4 or Layer 7, or a combination, to manage traffic. There are benefits and drawbacks to each solution.
Layer 4 load balancers work at the Transport layer to direct traffic without examining the contents.
Because they don't examine the traffic contents, Layer 4 load balancers save time in transit. However, this comes with trade-offs. Layer 4 load balancers know only the IP address, protocol, and TCP port. Knowing only a single IP address, the load balancer can monitor only a single service.
Layer 4 load-balancing benefits include:
Requires fewer resources (no content examination).
Distributes traffic at the Transport layer.
Layer 7 load balancers work at the Application layer and can inspect the traffic content and direct it accordingly.
Layer 7 load-balancing benefits include:
Needs only a single IP address.
Inspects content and can direct traffic.
Provides notification of failed service that can be taken offline.
Handles load balancer SSL termination.
Distributes traffic at the application layer and understands the destination URL.
SSL should terminate at the load balancer as this offers a centralized place to correct SSL attacks.
The ports that need to be load balanced include some, such as those for IMAP4 or POP3, that may not even be used in your Exchange organization.
TCP Port | Roles | Uses |
---|---|---|
25 | Mailbox | Inbound SMTP |
587 | Mailbox | Inbound SMTP for clients |
110 | Mailbox | POP3 clients |
143 | Mailbox | IMAP4 clients |
443 | Mailbox | HTTPS (Outlook on the web, AutoDiscover, web services, ActiveSync, MAPI over HTTP, RPC over HTTP, OAB, EAC) |
993 | Mailbox | Secure IMAP4 clients |
995 | Mailbox | Secure POP3 clients |
Server roles in Exchange Server
The reduced number of server roles for Exchange 2016 and Exchange 2019 simplifies Exchange implementation and hardware requirements. The number of server roles in Exchange 2016 and 2019 shrinks from seven to two: the Mailbox server and the Edge Transport server. The Mailbox server role includes Client Access services, while the Edge Transport server provides secure mail flow in Exchange 2016 and Exchange 2019, just as it did in earlier versions of Exchange.
In Exchange 2013, the Client Access server role made sure that when a user attempted to access their mailbox, the server proxied the request back to the Mailbox server actively serving the user's mailbox. This meant that services such as Outlook on the web (previously known as Outlook Web App) were rendered for the user on the Mailbox itself, removing any need for affinity.
The same functionality remains in Exchange 2016 and Exchange 2019. If two Mailbox servers host different mailboxes, they can proxy traffic for each other when necessary. The Mailbox server that hosts the active copy of the mailbox serves the user accessing it, even if the user connects to a different Mailbox server.
Read more about the server role changes in Exchange Server in the article, Exchange Server architecture.
- Mail relay
- Smart hosting.
- Agents that provide more antispam service.
- Agents that apply transport to control mail flow.
Although not required, the Edge Transport server sits in the perimeter network, as in earlier Exchange versions, to provide secure inbound and outbound mail flow for your Exchange organization.
Для этого:
Рис.1: Настройка делегирования на основном DNS сервере.
Рис.2: Настройка DNS-зоны на одном из серверов.
3. Для того, чтобы обеспечить “отказоустойчивость” решения, нужно настроить параметры обновления записей (см. рис.2). В качестве примера, я установил все настройки в 5 секунд. В рабочей среде вы должны серьезно обдумать эти значения, чтобы не получить DDOS на сервера, в случае большого количества клиентов. Т.е. надо найти золотую середину между допустимым временем простоя и количеством запросов на сервер от клиентов.
Protocols in Exchange Server
В чем отличие от round robin
Отличие в том, что если один из серверов не отвечает, то DNS не сможет запросить у него содержимое зоны и попытается разрезолвить IP адрес через другой DNS сервер. Такого в round robin не происходит!
Очевидно, что настройками TTL мы можем регулировать время, когда DNS зона будет запрашиваться заново и таким образом проверять работоспособность сервера.
Примечание: По факту, проверяется работоспособность службы DNS, а не самого сервера и уже тем более не Exchange`a, работающего на этом сервере.
Load balancing in Exchange 2016 and later build on the Microsoft high availability and network resiliency platform delivered in Exchange 2013. When this is combined with the availability of third-party load-balancing solutions (both hardware and software), there are multiple options for implementing load balancing in your Exchange organization.
Exchange architecture changes introduced in Exchange 2013 brought about the Mailbox server and Client Access server roles. Compare this to Exchange 2010, where Client Access, Mailbox, Hub Transport, and Unified Messages ran on separate servers.
Using minimal server roles, Exchange 2016 and 2019 delivers:
Simplified deployment with the Mailbox server running Client Access services and Edge Transport server roles.
Mail flow managed in the transport pipeline, which is the collection of services, connections, queues, and components that route messages to the Transport service categorizer on the Mailbox server.
High availability by deploying load balancers to distribute client traffic.
Answers
Its the simplest of the HA options available.
On Internal DNS:
Create host or CNAME records for each CAS server.
Reverse proxy should forward it to the CAS servers.
You can have 2 Public IPs, pointing towards your CAS servers internal IPs through NAT port mapping.
On DNS have two host records
Please “Vote As Helpful” if you find my contribution useful or “Mark As Answer” if it does answer your question. That will encourage me - and others - to take time out to help you.
Do you means priority for MX record?
Yes, the priority allows you to set up primary and backup mail servers, and the host with the lowest priority is considered the primary mail server. If the primary mail server is unavailable, the host sending mail should attempt to send the mail via the host with the next lowest priority, and so on.
Allen Wang
TechNet Community Support
Протоколы в Exchange Server
Вариант балансировки сетевого трафика на базе DNS
Балансировка сетевого трафика (NLB) – это очень важный и ответственный вопрос в теме обеспечения отказоустойчивости. Те, у кого есть возможность, конечно же не задумываясь покупают аппаратные балансировщики и живут спокойно, те у кого денег не так много, реализуют NLB на базе службы Windows Network Load Balancing. Но есть и те, кому приходится реализовывать задачу балансировки при помощи DNS round robin (попросту создав две или более А-записей с одним именем и разными IP адресами). Прямо скажем, round robin – это совсем не удачны вариант в плане именно отказоустойчивости.
В данной статье я предлагаю вам обсудить ещё один вариант балансировки на базе DNS и прошу высказать все свои “за” и “против” в комментах ниже.
Параметры балансировки нагрузки в Exchange Server
В приведенном ниже примере на нескольких серверах в группе обеспечения доступности баз данных размещаются серверы почтовых ящиков, где работают службы клиентского доступа. Это обеспечивает высокий уровень доступности, а серверы Exchange занимают меньше места. Клиент подключается к подсистеме балансировки нагрузки, а не напрямую к серверам Exchange. Для пар балансиров нагрузки не существует требования, однако рекомендуется развертывать в кластерах для повышения устойчивости сети.
Помните, что группы обеспечения доступности баз данных используют службы кластеров Microsoft. Эти службы не могут быть включены на том же сервере, что и балансировка сетевой нагрузки (NLB) Windows. Следовательно, если используются группы обеспечения доступности баз данных, включить Windows NLB нельзя. В таком случае можно воспользоваться сторонними программами и решениями для виртуальных модулей.
Простота имеет цену, однако в этом случае круглая малиновка DNS не балансирует трафик по-настоящему, так как программным образом не существует способа убедиться, что каждый сервер получает справедливую долю трафика. Кроме того, отсутствует мониторинг уровня обслуживания, чтобы при сбойе одной службы клиенты не перенаправлялись автоматически в доступную службу. Например, если Outlook в Интернете находится в режиме сбоя, клиенты видят страницу ошибки.
Для балансировки нагрузки с помощью DNS при внешней публикации требуется больше внешних IP-адресов. Это означает, что каждому серверу Exchange в организации потребуется внешний IP-адрес.
Существуют более элегантные решения для балансировки нагрузки трафика, например оборудование, распределяющее клиентский трафик с помощью транспортного уровня 4 или прикладного уровня 7. Балансиры нагрузки отслеживают Exchange клиентской службы, и при сбое службы балансиры нагрузки могут направлять трафик на другой сервер и отбирать проблемный сервер в автономном режиме. Кроме того, некоторая степень балансировки нагрузки гарантирует, что ни одному из серверов почтовых ящиков не приходится проксировать большую часть операций клиентского доступа.
Для управления трафиком службы балансировки нагрузки могут использовать 4-й или 7-й уровень либо их сочетание. У каждого решения есть свои преимущества и недостатки.
Подсистемы балансировки нагрузки 4-го уровня работают на транспортном уровне, направляя трафик без проверки содержимого.
Так как эти подсистемы не проверяют содержимое трафика, передача занимает меньше времени. Однако для этого приходится идти на компромиссы. Подсистемам балансировки нагрузки 4-го уровня известны только IP-адрес, протокол и TCP-порт. Зная только один IP-адрес, подсистема балансировки нагрузки может наблюдать только за одной службой.
Преимущества балансировки нагрузки на уровне 4 включают следующие преимущества:
низкие требования к ресурсам (проверка содержимого не выполняется);
распределение трафика на транспортном уровне.
Подсистемы балансировки нагрузки 7-го уровня работают на прикладном уровне. Они могут проверять содержимое трафика и направлять его соответствующим образом.
Преимущества балансировки нагрузки на уровне 7 включают следующие преимущества:
требуется только один IP-адрес;
проверка содержимого и возможность направления трафика;
уведомления об отказе служб, которые можно переводить в автономный режим;
завершение SSL-запросов в подсистеме балансировки нагрузки;
распределение трафика на прикладном уровне и анализ целевого URL-адреса.
SSL-запросы должны завершаться в подсистеме балансировки нагрузки, которая будет центральным расположением для защиты от атак с использованием SSL.
Некоторые порты, для которых требуется балансировка нагрузки (например, для протоколов IMAP4 и POP3), могут даже не использоваться в организации Exchange.
All replies
Its the simplest of the HA options available.
On Internal DNS:
Create host or CNAME records for each CAS server.
Reverse proxy should forward it to the CAS servers.
You can have 2 Public IPs, pointing towards your CAS servers internal IPs through NAT port mapping.
On DNS have two host records
Please “Vote As Helpful” if you find my contribution useful or “Mark As Answer” if it does answer your question. That will encourage me - and others - to take time out to help you.
how do i set the priority on public DNS? All i have is the Name, record type and target. Dont seem to have anywhere to set which server is used first?
Do you means priority for MX record?
Yes, the priority allows you to set up primary and backup mail servers, and the host with the lowest priority is considered the primary mail server. If the primary mail server is unavailable, the host sending mail should attempt to send the mail via the host with the next lowest priority, and so on.
Allen Wang
TechNet Community Support
how do i set the priority on public DNS? All i have is the Name, record type and target. Dont seem to have anywhere to set which server is used first?
Thanks
JK MCP
The beauty of DNS round robin lies in its simplicity. A and CNAME records are all equal, distributed evenly among all the requests, irrespective of the target server's status.
So if you have 2 records it would be 50-50 hits on both and you can't set a priority.
There is no standard procedure for deciding which address will be used by the requesting application, a few resolvers attempt to re list to give priority to numerically "closer" networks. Some desktop clients do try alternate addresses after a connection timeout of 30–45 seconds.
Please “Vote As Helpful” if you find my contribution useful or “Mark As Answer” if it does answer your question. That will encourage me - and others - to take time out to help you.
Теория
Статья описывает одну из технологий балансировки нагрузки, которая может быть реализована средствами DNS. Для перевода имени хоста в IP-адрес клиент DNS направляет серверу DNS рекурсивный запрос (т.е. запрос, на который сервер DNS возвращает клиенту либо ответ с IP адресом, либо ответ с ошибкой).
В подавляющем большинстве случаев в зонах DNS содержится только один IP адрес, соответствующий тому или иному имени хоста. А какой IP адрес будет возвращать клиенту сервер DNS, если зона содержит несколько записей типа A для одного и того же имени? Ответ простой: сервер DNS всегда возвращает клиенту все IP адреса, соответствующие запрашиваемому имени. А дальше клиент пытается связаться с первым IP адресом в списке и, если он не будет найден, делает попытку связаться со вторым адресом и т.д.
Поскольку адрес 20.0.0.1 идет первым в списке, клиент всегда будет пытаться связаться именно с сайтом по адресу 20.0.0.1. Получается, что сайты 30.0.0.1 и 40.0.0.1 используются только как пассивный резерв. До тех пор, пока "жив" сайт по адресу 20.0.0.1, сайты 30.0.0.1 и 40.0.0.1 не получат от клиента ни одного запроса.
Как сделать, чтобы запросы “доставались” всем хостам? Ответ простой: настроить на сервере DNS функцию Round robin.
На второй запрос от клиента или от другого сервера DNS будет возвращен ответ
В результате мы получаем динамическую балансировку запросов клиентов между несколькими хостами.
Практика
____________________________________________________________________________________
Load balancing and managed availability in Exchange Server
Monitoring the available servers and services is key to high availability networks. Since some load-balancing solutions have no knowledge of the target URL or the content of the request, this can introduce complexities for Exchange health probes.
Exchange 2016 and Exchange 2019 include a built-in monitoring solution, known as Managed Availability. Managed availability, also known as Active Monitoring, or Local Active Monitoring, is the integration of built-in monitoring and recovery actions with the Exchange high availability platform.
Managed Availability includes an offline responder. When the offline responder is invoked, the affected protocol (or server) is removed from service.
To ensure that load balancers do not route traffic to a Mailbox server that Managed Availability has marked as offline, load balancer health probes must be configured to check /healthcheck.htm, for example, .
Балансировка нагрузки Exchange 2016 г. и более позднее на основе платформы высокой доступности и устойчивости к сети Майкрософт, поставленной в Exchange 2013 г. Когда это сочетается с доступностью сторонних решений для балансировки нагрузки (как оборудования, так и программного обеспечения), существует несколько вариантов для реализации балансировки нагрузки в Exchange организации.
Используя минимальные роли сервера, Exchange 2016 и 2019 гг. обеспечивает:
упрощенное развертывание, так как на сервере почтовых ящиков устанавливаются службы клиентского доступа и роли пограничных транспортных серверов;
высокий уровень доступности за счет развертывания подсистем балансировки нагрузки для распределения клиентского трафика.
Роли сервера в Exchange Server
Сокращение числа ролей сервера в Exchange 2016 и Exchange 2019 упрощает Exchange и требования к оборудованию. Количество ролей сервера в Exchange 2016 и 2019 гг. сокращается с семи до двух: сервера почтовых ящиков и транспортного сервера Edge. Роль сервера почтовых ящиков включает службы клиентского доступа, в то время как edge Transport server обеспечивает безопасный поток почты в Exchange 2016 и Exchange 2019, как это было в предыдущих версиях Exchange.
В Exchange 2013 роль сервера клиентского доступа гарантировала, что когда пользователь пытался получить доступ к своему почтовому ящику, сервер проксировал запрос обратно на сервер почтовых ящиков, обслуживающий почтовый ящик этого пользователя. В связи с этим такие службы, как Outlook в Интернете (предыдущее название Outlook Web App), отрисовывались в самом почтовом ящике, избавляя от необходимости в сходстве.
Такие же функции сохраняются в Exchange 2016 и Exchange 2019 г. Если на двух серверах почтовых ящиков размещены разные почтовые ящики, при необходимости они могут проксировать трафик друг для друга. Сервер почтовых ящиков, на котором размещена активная копия почтового ящика, обслуживает пользователя, получающего доступ к нему, даже если этот пользователь подключается к другому серверу.
Подробнее об изменениях роли сервера в Exchange Server в статье Exchange Server архитектуре.
Роль сервера | Службы |
---|---|
Сервер почтовых ящиков | Использует службу EdgeSync для управления односторонней репликацией сведений о получении и конфигурации из Active Directory в экземпляр служб Active Directory облегченного доступа к каталогам на пограничном транспортном сервере. Копирует только сведения, необходимые для того, чтобы edge Transport выполняла антиспам и в течение всего потока электронной почты. |
Пограничный транспортный сервер | Управляет потоком обработки почты в Интернет и из него с помощью: • ретранслятор почты • интеллектуальный хостинг • агенты, которые предоставляют дополнительные службы антиспама • агенты, которые применяют транспорт для управления потоком почты Не является элементом леса Active Directory. |
Дополнительные статьи о транспортной службе читайте в статье Understanding the Transport service on Edge Transport servers.
Проверка работы DNS Round robin
В Windows Server опция Enable round robin включена по умолчанию. Достаточно в консоли DNS Manager открыть свойства DNS сервера и посмотреть вкладку Advanced.
Что такое DNS Round robin и как он работает-01
Что такое DNS Round robin и как он работает-02
Ping statistics for 20.0.0.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\>
Анализ кэша DNS на стороне клиента дает следующий результат:
C:\>ipconfig /displaydns
Windows IP Configuration
Теперь становится понятно, почему мы “пингуем” один и тот же хост 20.0.0.1. Сервер DNS возвращает клиенту все записи из зоны с указанием времени кэширования, равным по умолчанию 1 часу (или 3600 секундам). Поэтому до истечения времени кэширования (TTL – Time To Live) клиент больше не направляет к серверу DNS никаких новых запросов.
Возможные варианты:
постоянный сброс кэша на стороне клиента (плохой вариант);
установка времени кэширования, равное нулю, в свойствах зоны (плохой вариант, поскольку влияет на всю зону);
установка индивидуального времени кэширования на отдельных записях (хороший вариант).
Для настройки индивидуального времени кэширования в консоли DNS Manager требуется сначала включить режим View –> Advanced. Затем последовательно открываем свойства записей (в нашем примере это три записи www) и ставим время кэширования, равное нулю.
Что такое DNS Round robin и как он работает-03
Ping statistics for 40.0.0.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Файл зоны на сервере DNS при этом будет выглядеть так:
;
; Database file gorbunov.pro.dns for gorbunov.pro zone.
; Zone version: 7
;
www 0 A 20.0.0.1
0 A 30.0.0.1
0 A 40.0.0.1
Добавления нуля в записи типа A можно сделать и вручную непосредственно в файле зоны.
Технология DNS Round robin часто применяется для динамической балансировки нагрузки между зеркальными хостами. Она значительно проще в реализации, чем вариант настройки для тех же целей кластера NLB. При настройке DNS Round robin на серверах Windows не забывайте, что настройки по умолчанию для сервера DNS не позволяют в полной мере реализовать балансировку запросов и требуется ручная конфигурация сервера.
Вы попали на блог, целиком и полностью посвященный продуктам компании Microsoft. В основном речь будет идти про системы корпоративных коммуникаций на базе Exchange Server.
Answers
Its the simplest of the HA options available.
On Internal DNS:
Create host or CNAME records for each CAS server.
Reverse proxy should forward it to the CAS servers.
You can have 2 Public IPs, pointing towards your CAS servers internal IPs through NAT port mapping.
On DNS have two host records
Please “Vote As Helpful” if you find my contribution useful or “Mark As Answer” if it does answer your question. That will encourage me - and others - to take time out to help you.
Do you means priority for MX record?
Yes, the priority allows you to set up primary and backup mail servers, and the host with the lowest priority is considered the primary mail server. If the primary mail server is unavailable, the host sending mail should attempt to send the mail via the host with the next lowest priority, and so on.
Allen Wang
TechNet Community Support
четверг, 11 октября 2012 г.
Load balancing deployment scenarios in Exchange Server
Exchange 2016 introduced significant flexibility for your namespace and load-balancing architecture. With many options for deploying load balancing in your Exchange organization, from simple DNS to sophisticated third-party Layer 4 and Layer 7 solution, we recommend that you review them all in light of your organization's needs.
The following scenarios come with benefits and limitations, and understanding each is key to implementing the solution that best fits your Exchange organization:
Scenario A Single namespace, no session affinity: Layer 4 or Layer 7
Scenario B Single namespace, no session affinity: Layer 7
Scenario C Single namespace with session affinity, Layer 7
Scenario D Multiple namespaces and no session affinity, Layer 4
Scenario A Single namespace, no session affinity: Layer 4 or Layer 7
From the perspective of the load balancer in this example, health is per-server and not per-protocol for the designated namespace. Administrators will have to choose which virtual directory they want to target for the health probe; we recommend that you choose a heavily used virtual directory. For example, if the majority of your users use Outlook on the web, then choose the Outlook on the web virtual directory in the health probe.
As long as the Outlook on the web health probe response is healthy, the load balancer keeps the destination Mailbox server in the load-balancing pool. However, if the Outlook on the web health probe fails for any reason, then the load balancer removes the destination Mailbox server from the load-balancing pool for all requests associated with that namespace. This means that if the health probe fails, all client requests for that namespace is directed to another server, regardless of protocol.
Scenario B Single namespace, no session affinity: Layer 7
We recommend this configuration for Exchange 2016 and Exchange 2019. The load balancer is configured to check the health of the destination Mailbox servers in the load-balancing pool, and a health probe is configured on each virtual directory.
For example, as long as the Outlook on the web health probe response is healthy, the load balancer will keep the destination Mailbox server in the Outlook on the web load-balancing pool. However, if the Outlook on the web health probe fails for any reason, then the load balancer removes the target Mailbox server from the load-balancing pool for Outlook on the web requests. In this example, health is per-protocol, which means that if the health probe fails, only the affected client protocol is directed to another server.
Scenario C Single namespace with session affinity, Layer 7
However, enabling session affinity decreases capacity and utilization. This is because the more involved affinity options, cookie-based load balancing, or Secure Sockets Layer (SSL) session-ID, require more processing and resources. We recommend that you check with your vendor on how session affinity affects your load-balancing scalability.
As in the previous scenario, as long as the Outlook on the web health probe response is healthy, the load balancer keeps the destination Mailbox server in the Outlook on the web load-balancing pool. However, if the Outlook on the web health probe fails for any reason, then the load balancer removes the target Mailbox server from the load-balancing pool for Outlook on the web requests. Here, health is per-protocol, which means that if the health probe fails, only the affected client protocol is directed to another server.
Scenario D Multiple namespaces and no session affinity
This scenario provides per-protocol health checking while not requiring complex load-balancing logic. The load balancer uses Layer 4 and isn't configured to maintain session affinity. The load balancer configuration checks the health of the destination Mailbox servers in the load-balancing pool. In this setting, the health probes are configured to target the health of each virtual directory, as each virtual directory has a unique namespace. Because it's configured for Layer 4, the load balancer doesn't know the URL is being accessed, yet the result is as if it does know. Since health is per-protocol, if the health probe fails, only the affected client protocol is directed to another server.
Описание
Итак, что же у нас получилось:
Предполагается, что ваш DNS сервер будет приблизительно равномерно распределять запросы между 2-я DNS серверами, указанными в делегировании.
Балансировка нагрузки и управляемость в Exchange Server
Наблюдение за доступными серверами и службами ключ к созданию сетей с высоким уровнем доступности. Поскольку некоторые решения для балансировки нагрузки не знают целевой URL-адрес или содержимое запроса, это может привести к сложности для Exchange зондов.
Exchange 2016 и Exchange 2019 г. включает встроенное решение мониторинга, известное как Managed Availability. Управляемое доступность, также известное как Active Monitoring или Local Active Monitoring, — это интеграция встроенных действий мониторинга и восстановления с Exchange платформой высокой доступности.
Служба управляемой доступности включает автономное отвечающее устройство. При вызове автономного отвечающего устройства соответствующий протокол (или сервер) удаляется из службы.
Чтобы балансиры нагрузки не перенаправили трафик на сервер почтовых ящиков, помеченный как автономный, необходимо настроить зонды работоспособности балансиров нагрузки для проверки /healthcheck.htm, например, .
Дополнительные информацию об управляемой доступности в управляемой доступности.
Результат
Сценарии развертывания балансировки нагрузки в Exchange Server
Exchange 2016 г. обеспечивает значительную гибкость пространства имен и балансировки нагрузки. Учитывая разнообразие вариантов развертывания для подсистем балансировки нагрузки в организации Exchange от простого DNS до сложных сторонних решений 4-го и 7-го уровней, рекомендуем изучить их все, исходя из потребностей организации.
У описанных ниже сценариев есть свои преимущества и ограничения. Понимание их особенностей ключ к реализации решения, идеально подходящего для вашей организации Exchange.
Сценарий А. Одно пространство имен без сходства сеансов: уровень 4 или 7
Сценарий Б. Одно пространство имен без сходства сеансов: уровень 7
Сценарий В. Одно пространство имен со сходством сеансов, уровень 7
Сценарий Г. Несколько пространств имен без сходства сеансов, уровень 4
Сценарий А. Одно пространство имен без сходства сеансов: уровень 4 или 7
С точки зрения балансира нагрузки в этом примере, состояние здоровья является на сервере, а не по протоколу для назначенного пространства имен. Администраторам придется выбирать, какой виртуальный каталог они хотят нацелить для зонда здоровья; Мы рекомендуем выбрать сильно используемый виртуальный каталог. Например, если большинство пользователей используют Outlook в Интернете, выберите виртуальный каталог Outlook в Интернете в зонде здоровья.
Пока ответ зонда Outlook в Интернете является здоровым, балансировка нагрузки сохраняет сервер почтовых ящиков назначения в пуле балансировки нагрузки. Однако если зонд Outlook в Интернете по какой-либо причине не удается, то балансировка нагрузки удаляет сервер почтового ящика назначения из пула балансировки нагрузки для всех запросов, связанных с этим пространством имен. Это означает, что в случае сбой зонда здоровья все клиентские запросы для этого пространства имен направляются на другой сервер, независимо от протокола.
Сценарий Б. Одно пространство имен без сходства сеансов: уровень 7
Мы рекомендуем эту конфигурацию для Exchange 2016 и Exchange 2019. Балансировщик нагрузки настроен для проверки состояния серверов почтовых ящиков назначения в пуле балансировки нагрузки, а в каждом виртуальном каталоге настроен зонд здоровья.
Например, пока ответ Outlook в Интернете для зонда здоровья является здоровым, балансировка нагрузки будет хранить сервер почтовых ящиков назначения Outlook в Интернете пула балансировки нагрузки. Однако если зонд Outlook в Интернете по какой-либо причине не удается, то балансировка нагрузки удаляет целевой сервер почтовых ящиков из пула балансировки нагрузки для Outlook в Интернете запросов. В этом примере работоспособность проверяется для каждого протокола, то есть в случае неудачной проверки работоспособности только соответствующий клиентский протокол перенаправляется на другой сервер.
Сценарий В. Одно пространство имен со сходством сеансов, уровень 7
Однако отключение сходства сеансов приводит к снижению производительности и уровня использования. Это потому, что для более активного использования параметров сродства, балансировки нагрузки на основе файлов cookie или secure Sockets Layer (SSL) session-ID требуется больше обработки и ресурсов. Рекомендуется проверить у поставщика, как сродство сеансов влияет на масштабируемость для балансировки нагрузки.
Как и в предыдущем сценарии, пока ответ Outlook в Интернете для зонда здоровья является здоровым, балансировка нагрузки сохраняет сервер почтового ящика назначения в пуле Outlook в Интернете балансировки нагрузки. Однако если зонд Outlook в Интернете по какой-либо причине не удается, то балансировка нагрузки удаляет целевой сервер почтовых ящиков из пула балансировки нагрузки для Outlook в Интернете запросов. В этом случае работоспособность проверяется для каждого протокола, то есть в случае неудачной проверки работоспособности только соответствующий клиентский протокол направляется на другой сервер.
Сценарий Г. Несколько пространств имен без сходства сеансов
Этот сценарий обеспечивает проверку состояния по протоколу, не требуя сложной логики балансировки нагрузки. Балансировка нагрузки использует слой 4 и не настроена для поддержания сродства сеанса. Конфигурация балансировки нагрузки проверяет состояние серверов почтовых ящиков назначения в пуле балансировки нагрузки. В этом параметре зонды здоровья настроены для целевого состояния каждого виртуального каталога, так как каждый виртуальный каталог имеет уникальное пространство имен. Так как он настроен для уровня 4, балансивчик нагрузки не знает, что к URL-адресу можно получить доступ, но результат такой, как если бы он знал. Так как состояние здоровья за протоколом, если зонд состояния не удается, на другой сервер направляется только пострадавший клиентский протокол.
Читайте также: