Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Введение
Тип записи ресурса в системе доменных имен
Type of resource record in the Domain Name System
SRV-запись (Service record) – это спецификация данных в системе доменных имен, определяющая местоположение серверов для указанных служб, то есть имя хоста и номер порта. Она определена в RFC 2782, и её код типа равен 33. Некоторые интернет-протоколы, такие как протокол инициирования сеансов (SIP) и протокол расширяемой передачи сообщений и присутствия (XMPP), часто требуют поддержки SRV сетевыми элементами.
A Service record (SRV record) is a specification of data in the Domain Name System defining the location, i. e., the hostname and port number, of servers for specified services. It is defined in RFC 2782, and its type code is 33. Some Internet protocols such as the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) often require SRV support by network elements.
Обеспечение высокой доступности услуг
Поле приоритета определяет порядок использования данных записи. Клиенты должны сначала использовать записи SRV с наименьшим числовым значением приоритета и переходить к записям с более высоким значением, если соединение не установлено. Если для службы существует несколько записей SRV с одинаковым значением приоритета, клиенты должны распределять нагрузку между ними пропорционально значениям их полей веса. В следующем примере поля приоритета и веса используются для обеспечения комбинации балансировки нагрузки и резервного обслуживания. Первые три записи имеют приоритет 10, поэтому клиенты будут использовать значение поля веса для определения, к какому серверу (комбинации хоста и порта) обращаться. Сумма всех трех значений равна 100, поэтому bigbox.example.com будет использоваться в 60% случаев. Два хоста, smallbox1 и smallbox2, будут использоваться для 40% всех запросов, при этом половина запросов будет направлена на smallbox1, а другая половина – на smallbox2. Если bigbox недоступен, эти два оставшихся сервера будут разделять нагрузку поровну, поскольку каждый из них будет выбран в 50% случаев. Если все три сервера с приоритетом 10 недоступны, будет выбрана запись со следующим наименьшим значением приоритета, то есть backupbox.example.com. Это может быть машина в другом физическом местоположении, предположительно не подверженная воздействию факторов, которые могли бы привести к недоступности первых трех хостов. Балансировка нагрузки, предоставляемая записями SRV, по своей сути ограничена, поскольку информация практически статична. Текущая нагрузка на серверы не учитывается, если значения TTL недостаточно малы (около минуты или меньше), чтобы значения приоритета (или веса) могли быть быстро обновлены.
The priority field determines the precedence of the use of the record's data. Clients should use the SRV records with the lowest numbered priority value first, and fall back to records of higher value if the connection fails. If a service has multiple SRV records with the same priority value, clients should load balance them in proportion to the values of their weight fields. In the following example, both the priority and weight fields are used to provide a combination of load balancing and backup service. The first three records share a priority of 10, so the weight field's value will be used by clients to determine which server (host and port combination) to contact. The sum of all three values is 100, so bigbox. example. com will be used 60% of the time. The two hosts, smallbox1 and smallbox2 will be used for 40% of requests total, with half of them sent to smallbox1, and the other half to smallbox2. If bigbox is unavailable, these two remaining machines will share the load equally, since they will each be selected 50% of the time. If all three servers with priority 10 are unavailable, the record with the next lowest priority value will be chosen, which is backupbox. example. com. This might be a machine in another physical location, presumably not vulnerable to anything that would cause the first three hosts to become unavailable. The load balancing provided by SRV records is inherently limited since the information is essentially static. The current load of servers is not taken into account unless TTL values are low enough (around a minute or lower) that the priority (or weight) values can be quickly updated.