Установка Database Availability Group в Exchange 2010

Установка Database Availability Group в Exchange 2010

11.01.2012
itpro
Exchange
комментария 2

В Microsoft Exchange Server 2010 появилась новая технология обеспечения высокой доступности под названием группы высокой доступности — Database Availability Group (DAG). В этой статье мы познакомимся с тем, как работаеттехнология Database Availability Group в Exchange Server 2010, а также опишем процесс установки и настройки DAG на Exchange Server 2010 SP1 и Windows Server 2008 R2.

Синхронизация копий баз данных в кластерах Exchange 2007/2010

Как известно, между базами данных почтовых ящиков, в кластерных решениях MS Exchange 2007/2010, информация реплицируется при помощи файлов журнала транзакций (transaection logs), далее мы их будем просто называть логами транзакций. Давайте разберемся подробнее как этот механизм работает.

Копирование логов транзакций

Итак, логи транзакций генерируются на сервере с активной базой данных, затем копируются на пассивный сервер и проигрываются в базу.

На Exchange 2010 процессом копирования логов управляет служба Replication Service, которая самостоятельно отправляет (push) логин на все сервера баз банных в DAG группе. Этот процесс кардинально отличается от аналогичного в Exchange 2007, где вместо push`a имеет место механизм pull, т.е. сервер с пассивной копией “забирает” логи с активного сервера.

Сам процесс передачи файлов также отличается – в Exchange 2010 для каждой базы данных открывается свой собственный TCP сокет, при этом в Exchange 2007 используется SMB протокол, и более того, открывается только одна сессия на сервер.

Примечание: Перед пересылкой логи в Exchange 2010 сжимаются! По оценкам Microsoft это снижает трафик репликации примерно на 20%.

Проигрывание логов (Transaction log replay)

После того, как информация будет передана на сервер с пассивной копией, она должна быть “проиграна” (replays) в базу. В Exchange 2010 за это отвечает служба Information Store, в отличи от Exchange 2007, где работала служба MS Exchange Replication Service. Использование IS дает преимущество в том, что IS всегда “знает” в каком состоянии база. В Exchange 2007 процесс заполнения базы происходил за пределами IS, таким образом кэш в памяти сервера не мог начать использоваться быстро и при активации пассивной копии Information Store`y приходилось очень много читать с диска и заполнять кэш, для того, чтобы быстро обеспечить пользователей оперативной информацией, в результате при переключении I/O резко возрастало.

Примечание: DAG — граница репликации данных. Т.е. логи нельзя проиграть в базу из другого DAG-a.

Несмотря на все описанные выше различия, принципиально, при переходе от Exchange 2007 к 2010, процесс копирования остался прежним и заключается в следующих этапах:

• Закрытые Information Store-ом файлы логов копируются на все сервера, где есть копии базы. Копирование происходит в определенную папку. Файлы обрабатываются "инспектором". Процесс этот асинхронный — как появляется новый закрытый лог, так он сразу копируется.

Исключение появилось в Exchange 2010 SP1, где был внедрен новый тип репликации — Block replication, т.е. репликация идет блоками, это значит, что SP1 не ждет когда файл лога будет закрыт. Как только данные записаны на диск, они сразу реплицируются. Если в процессе Block replication возникают ошибки или сложности (например накопилось более 4-х логов в очереди, в следствии большой загруженности сети), то Exchange переходит обратно в File Mode Replication.

• Инспектор постоянно проверяет "свою папку" на предмет наличия новых файлов и проверяет каждый файл на целостность. Если файл проходит проверку, то он перемещает его в другую папку (replay directory). Если файл проверку не проходит, то выполняется попытка его повторной загрузки. Если эта попытка оказывается неудачной, то копия базы считается плохой и инициируется процесс повторного заполнения базы (reseed).
• Log replayer проигрывает полученные файлы из папки “replay directory” в базу каждые 60 сек., или каждые 10 новых логов. Это процесс выполняется при помощи службы Information Store`a. Процесс похож на soft recover выполняемый утилитой eseutil.
• Truncate deletor удаляет проигранные Log replayer`ом файлы. Более подробно про удаление файлов транзакций мы поговорим в следующей статье.
• Механизм Incremental seeder отвечает за то, что база находится в консистентном состоянии после восстановления или переключения.

Состояние базы и количество логов в очередях на копирование и проигрывание можно посмотреть в EMC (см. рис.)

Заключение

На этом все, что я хотел рассказать про синхронизацию копий баз данных. Далее поговорим подробнее про жизненный цикл самих файлов транзакций.

Интеграция с продуктами Google и Apple

«Битрикс24 в коробке» интегрирован с продуктами Google и Apple благодаря поддержке форматов CardDav и CalDav, реализованной в продукте.

Календарь Google можно подключить к корпоративному порталу, работать с ним на мобильных устройствах Android, синхронизировать обновление данных.

Интеграция с продуктами Apple позволяет подключить календари к устройствам на Mac OS X, iPad, iPhone, обеспечить двусторонний обмен данными, а также загрузить контакты на Mac OS X, iPad, iPhone.

Представители Microsoft заявили, что Exchange Server 2007 ‘создан безопасным’. Exchange 2007 был разработан и создан в соответствии с жизненным циклом разработки безопасности компьютеризации, заслуживающей доверия (Trustworthy Computing Security Development Lifecycle (TWC)), который впервые был представлен в октябре 2002 года. Microsoft многое изменила в этой системе, а различные усовершенствования связанные с безопасностью, были интегрированы в Exchange Server 2007. Представители Microsoft утверждают, что Exchange Server 2007 более безопасен, чем все предыдущие версии Exchange.

Безопасен по умолчанию

Microsoft попыталась защитить Exchange Server 2007 с помощью существующих технологий безопасности. Одной из задач было обеспечение того, чтобы практически каждый важный бит трафика был зашифрован по умолчанию. Компания выполнила эту задачу за исключением кластеров коммуникаций протокола Server Message Block (SMB) и Unified Messaging (UM). Exchange Server 2007 – первая система для работы с сообщениями от Microsoft, использующая сертификаты self-signed. Вдобавок, Exchange Server 2007 использует технологию Kerberos для специальных соединений, Secure Sockets Layer (SSL) и других приемов шифрования.

Сертификаты

Exchange 2007 использует сертификаты X.509 для создания безопасных Transport Layer Security (TLS) и Secure Sockets Layer (SSL) каналов передачи для соединения с такими протоколами, как HTTPS, SMTP, IMAP4 и POP3.

Обратите внимание:доступ POP3 и SMTP дезактивирован по умолчанию, как и в предыдущих версиях Exchange Server.

Exchange Server 2007 использует сертификаты для нескольких компонентов.

SMTP

Сертификаты используются для шифровки и аутентификации Безопасности Домена (Domain Security) (новая характеристика для Exchange Server 2007) между различными организациями Exchange. Сертификаты используются для соединений между серверами Hub Transport и Edge Transport. Любое SMTP соединение между серверами Hub Transport зашифровано.

EdgeSync синхронизация

Exchange Server 2007 использует сертификаты self-signed для шифрования LDAP соединений между сервером Edge Transport при ссылке ADAM и внутренним сервером активной директории, через который служба Microsoft Exchange EdgeSync соединяется с активной директорией для копирования информации активной директории в сообщение об автоматическом установлении соединения (ADAM) на сервере Edge Transport.

POP3 и IMAP4

Exchange Server 2007 использует сертификаты для аутентификации и шифровки каждой сессии между клиентами Post Office Protocol version 3 (POP3) и Internet Message Access Protocol version 4 (IMAP4) и сервером Exchange Server 2007.

Unified Messaging

Сертификаты используются для зашифровки SMTP сессий в серверах Hub Transport и в канале Unified Messaging (UM) IP.

AutoDiscover

Сертификаты используются для зашифровки соединений HTTP между клиентом и сервером с клиентским доступом (Client Access Server (CAS)).

Приложения клиентского доступа (Client Access)

Exchange Server 2007 использует сертификаты для зашифровки соединений между серверами клиентского доступа CAS и такими клиентами, как Outlook 2007 (Outlook Anywhere, также известный как RPC через HTTPS), Microsoft Outlook Web Access (OWA), и Exchange ActiveSync.

В целях безопасности, Microsoft рекомендует использовать сертификаты, созданные вашими внутренними органами сертификации или независимыми сертификационными органами, если у вас есть много клиентов, получающих доступ к Exchange Server 2007 с компьютеров, не входящих в группу домена.

Коннекторы сообщений (Messaging connectors)

Exchange Server 2007 использует несколько коннекторов для распределения трафика от служб источника к месту назначения. Exchange Server 2007 использует два разных типа коннекторов. Коннекторы для входящего трафика, которые можно настроить на каждом сервере Exchange Server 2007, и один или более коннекторов для исходящего почтового трафика, сфокусированных на Exchange по всей организации.

Exchange Server 2007 поддерживает множество различных механизмов аутентификации для защиты передачи сообщений, для защиты аутентификации или и того, и другого.

• Протокол защиты безопасности транспортного уровня (Transport Layer Security (TLS)).
• Защиту домена (Domain Security (Mutual Auth.- протокол TLS с двусторонней авторизацией)).
• Основную аутентификацию после запуска TLS (Basic Authentication).
• Аутентификацию Exchange Server.
• Интегрированную аутентификацию Windows.

Рисунок 1: Аутентификация коннектора

Вы можете прочитать больше о защите SMTP потока сообщений между различными организациями Exchange Server 2007 в предыдущей статье, опубликованной на MSExchange.org. Ссылки даны ниже.

Сервер Microsoft Edge Transport

Функция Microsoft Edge Transport Server – это функция, которая должна быть установлена исключительно на машинах с Windows Server 2003 или Windows Server 2008. Серверы Edge Transport – это релейные почтовые серверы, которые обладают интегрированными функциями Anti Spam и дополнительными функциями антивируса Microsoft Forefront Edge Security или продукции других производителей. Microsoft Edge Transport Server установлен в рабочую группу Windows и не является частью домена. Edge Transport Server использует AD/AM (Active Directory Application Mode) для синхронизации важных данных активной директории с сервером Edge Transport Server. Процесс синхронизации называется Edge sync.

Серверы Edge Transport Server обладают следующими характеристиками:

• Фильтрация контента (Content Filtering)
• Допуск IP и поставщик блок-листа (IP Allow and Block List Provider)
• Фильтрация отправителя (Sender Filtering)
• Репутация отправителя (Sender Reputation)
• SMTP Tarpiting

Рисунок 2: служба Anti Spam сервера Edge Server

Microsoft Forefront

Microsoft Forefront – это решение Anti Virus и Anti Spam от Microsoft, доступное для таких продуктов Microsoft, как Exchange Server 2007, Microsoft Sharepoint Portal Server, Microsoft Windows клиенты и т.п. Одно решение для Microsoft Exchange – это Microsoft Forefront Edge Security. Вы можете использовать Forefront Edge Security на серверах Microsoft Edge Transport и Hub Transport, но рекомендуется использовать Forefront Edge Server Security в DMZ на серверах Microsoft Edge Transport.

Функции Microsoft Forefront Security

• Обеспечивает уровневую защиту с помощью Multiple Scan Engine Management для обеспечения безопасности почтовых систем.
• Обеспечивает расширенные возможности сканирования для большей эффективности и гибкости, включая:
• Сканирование в память (“In-memory”), снижающее воздействие на сервер Exchange для оптимальной защиты и эффективности.
• Сканирование различных баз данных и объектов хранения информации в реальном времени, запланированное или по требованию.
• Полная защита Outlook Web Access.
• Сканирование SMTP и Exchange Information Store для более надежной защиты и производительности.
• Сканирование сообщений агентов пересылки MTA для всех сообщений, направляемых через Коннекторы Exchange MTA Connectors (X.400, MS Mail, CC Mail, и т.д.).
• Включает одобренное Microsoft сканирование на вирусы встроенных программных интерфейсов приложений для Exchange 2000 и 2003.
• Минимизирует риск получения спама worm-generated spam и защищает информационную базу (Information Store) посредством Forefront Worm Purge.
• Определяет все сообщения с нежелаемыми вложениями посредством гибких правил фильтрации файлов.
• Отправляет зараженные вложения в карантин с помощью Forefront Quarantine Manager.
• Автоматически выгружает последние подписи вирусов.
• Дает сигнал администратору о наличии вирусов и сканирует события посредством e-mail, протоколов событий, и SMTP пейджеров.
• Включает различные настраиваемые отказы для исходящих сообщений, основанные на критериях имени отправителя, адресата и домена, устанавливаемые администраторами.

Рисунок 3: Microsoft Forefront Security

Помощник настройки безопасности (Security Configuration Wizard (Windows Server 2003 SP1))

Exchange 2007 обеспечивает шаблон SCW для каждой роли сервера Exchange 2007. Используя этот шаблон SCW, вы можете настраивать конфигурацию Windows Server 2003 для закрытия сервисов и портов, которые не нужны для работы каждой роли сервера Exchange. Когда вы используете Security Configuration Wizard, вы создаете шаблонный XML файл, который можно использовать для защиты этого или другого сервера Exchange.

Так как SCW был впервые представлен на Windows Server 2003 SP1 ‘ (прежде чем Exchange Server 2007 стал RTM), вам нужно активировать SCW, чтобы настроить Exchange Server 2007. Exchange Server 2007 идет с двумя SCW файлами конфигурации (config files), которые нужно установить на сервере, на котором вы хотите запустить SCW.

Для серверов Hub Transport

scwcmd register /kbname:Ex2007KB /kbfile:”%programfiles%MicrosoftExchange ServerscriptsExchange2007.xml

Для серверов Edge Transport

scwcmd register /kbname:Ex2007EdgeKB /kbfile:”%programfiles%MicrosoftExchange Serverscripts Exchange2007Edge.xm

Заключение

В этой части мы обсудили то, насколько безопасен Exchange Server 2007 и его субкомпоненты, и то, насколько Edge Transport Servers, Anti Spam и Antivirus технологии могут улучшить безопасность. В третьей статье вам будет показано, как защищать клиентский доступ к Exchange Server 2007, а также рассказано о некоторых необходимых изменениях в конфигурации Exchange Server 2007.

Пожалуйста, обратите внимание на то, что данная статья не концентрируется на всех новых улучшениях и функциях безопасности Exchange Server 2007.

Автор: Марк Гроут(Mark Grote)

Этот пост February 28, 2008 at 2:08 pm опубликовал molse в категории Microsoft Exchange. Желающие могут оформить RSS подписку на комменты. Both comments and trackbacks are currently closed.

Ошибка при перемещении почтового ящика Exchange 2016

Перенос почтового ящика из одной базы в другую — процедура самая обычная и не вызывающая особых сложностей. Но бывают исключения.

История такая: перемещаю ящик с помощью PowerShell, и, как обычно, мониторю процесс переноса такой вот командой:

Get-MoveRequest | where <[H1toH2] .status -ne "completed">| Get-MoveRequestStatistics | ft -a displayname,status*,percent

Сначала ящик едет довольно бодро, но потом процесс останавливается на 95% и замирает в состоянии StalledDueToTarget_DataGuaranteeWait. Это состояние длится довольно долго, после чего процесс переноса завершается ошибкой.

Статус ошибки не указывает на причину, поэтому вывожу более подробную информацию:

Get-MoveRequest | where < .status -ne "completed">| Get-MoveRequestStatistics | fl *failure*, message

Получаю вот такое сообщение, в котором говорится примерно следующее: «Не удалось реплицировать изменения почтового ящика. База данных не удовлетворяет ограничению SecondCopy потому что время фиксации изменений 04.09.2020 10:07:15 не гарантирует время репликации 31.12.9999 23: 59: 59».

Не очень внятное объяснение, особенно смущает дата из недалекого будущего. Но понятно, куда примерно копать. На серверах настроен DAG (Database Availability Group), база, в которую перемещается ящик, имеет копию, и видимо между базами есть проблемы с репликацией.

Проверяю состояние копий базы командой:

Get-MailboxDatabaseCopyStatus -Identity db10

Как ни странно, все в полном порядке.

Тогда проверяю работу репликации на сервере, на котором располагается база:

Test-ReplicationHealth -Server mbx2

И понимаю, что я сам себе злобный Буратино. Когда то давно, по уже забытой причине, я запретил автоматическую активацию копии базы на другом сервере. При этом репликация между базами продолжала исправно работать, но переключение на копию было невозможно. Именно этот факт являлся причиной ошибки и после снятия запрета ящик успешно переехал.

На этом история завершилась. А в качестве заключения немного теории.

Data Guarantee API

Exchange Server включает в себя функционал Data Guarantee API, который используется службой репликации почтовых ящиков (Mailbox Replication Service, MRS) для проверки состояния системы копирования почтовых баз на основе определенных настроек. В частности, Data Guarantee API может использоваться для:

• Проверки Replication Health — подтверждение того, что доступно заданное число копий почтовой базы.
• Проверки Replication Flush — подтверждение того, что необходимые файлы журналов успешно применены к заданному числу копий почтовой базы.

После выполнения проверки API возвращает следующую информацию:

Статус

• Retry — возвращается как результат промежуточных ошибок, которые делают невозможным проверку состояния почтовой базы.
• Satisfied — возвращается, когда почтовая база соответствует заданным условиям или база не реплицируется.
• NotSatisfied — возвращается, когда почтовая база не соответствует заданным условиям. Кроме того возвращается информация о том, почему получен код NotSatisfied.

Время ожидания повторной проверки

• Если информация о копировании не получена, то время ожидания по умолчанию составляет 10 секунд.
• Если не найдено ни одной здоровой копии почтовой базы, то время ожидания по умолчанию составляет 2 минуты.
• Если здоровая копия почтовой базы найдена, но она отстает в репликации, то время ожидания по умолчанию составляет 1 минуту.

Максимально возможное время ожидания 10 минут.

DataMoveReplicationConstraint

Каждая база имеет свойство DataMoveReplicationConstraint, которое определяет, сколько копий почтовой базы должно быть возвращено в запросе. DataMoveReplicationConstraint может принимать следующие значения:

• None — значение по умолчанию, присваивается при создании базы. При значении None условия в Data Guarantee API игнорируются. Это значение должно использоваться только для почтовых баз, которые существуют в единственном экземпляре и не реплицируются.
• SecondCopy — как минимум одна пассивная копия базы должна соответствовать условиям Data Guarantee API. Это значение по умолчанию, которое присваивается при создании копии базы.
• SecondDatacenter — как минимум одна копия базы в другом сайте Active Directory должна соответствовать условиям Data Guarantee API.
• AllDatacenters — как минимум одна копия базы в каждом сайте Active Directory должна соответствовать условиям Data Guarantee API.
• AllCopies — все копии почтовой базы должны соответствовать условиям Data Guarantee API.

Check Replication Health

Когда Data Guarantee API определяет «здоровье» инфраструктуры копий почтовых баз, вычисляются следующие параметры:

Если DataMoveReplicationConstraint имеет значение SecondCopy, то для данной базы по крайней мере одна пассивная копия должна:

• Быть в состоянии healthy.
• Иметь очередь воспроизведения (replay queue) с задержкой не более 10 минут.
• Иметь длину очереди копирования (copy queue) не более 10.
• Средняя длина очереди копирования (average copy queue length) не более 10. Средняя длина очереди копирования вычисляется на основе количества запросов приложения к состоянию базы данных.

Если DataMoveReplicationConstraint имеет значение SecondDatacenter, то для данной базы по крайней мере одна пассивная копия в другом сайте Active Directory должна:

• Быть в состоянии healthy.
• Иметь очередь воспроизведения (replay queue) с задержкой не более 10 минут.
• Иметь длину очереди копирования (copy queue) не более 10.
• Средняя длина очереди копирования (average copy queue length) не более 10.

3. Если DataMoveReplicationConstraint имеет значение AllDatacenters, то для данной почтовой базы активная копия должна быть смонтирована, а пассивная копия в каждом сайте Active Directory должна:

• Быть в состоянии healthy.
• Иметь очередь воспроизведения (replay queue) с задержкой не более 10 минут.
• Иметь длину очереди копирования (copy queue) не более 10.
• Средняя длина очереди копирования (average copy queue length) не более 10.

4. Если DataMoveReplicationConstraint имеет значение AllCopies, то для данной почтовой базы активная копия должна быть смонтирована, а все пассивные копии почтовой базы должны:

• Быть в состоянии healthy.
• Иметь очередь воспроизведения (replay queue) с задержкой не более 10 минут.
• Иметь длину очереди копирования (copy queue) не более 10.
• Средняя длина очереди копирования (average copy queue length) не более 10.

Check Replication Flush

Data Guarantee API может также использоваться для проверки того, что заданное число копий почтовой базы применяет требуемые транзакционные журналы. Это проверяется сравнением временной метки последнего примененного журнала с временной меткой подтверждения от вызывающего сервиса (в большинстве случаев это временная метка последнего файла журнала, который содержит требуемую информацию) плюс 5 секунд (это связано с отклонениями системного времени). Если метка времени применения больше, чем время подтверждения, то проверка возвращает статус Satisfied, если меньше — возвращает статус NotSatisfied.

Mailbox Replication Service

При перемещении ящиков служба репликации MRS вызывает Data Guarantee API несколько раз за время выполнения запроса на перемещение. Перемещение выполняется в следующем порядке:

• Запрос на перемещение обновляет Active Directory и помещает сообщение в системный почтовый ящик, расположенный в почтовой базе целевого сайта Active Directory. Затем MRS запрашивает Data Guarantee API, чтобы определить здоровье целевой инфраструктуры копий почтовых баз. Пока возвращаемый статус равен Satisfied, выполнение запроса на перемещение будет продолжаться.
• MRS начинает перемещение информации, клонируя структуру почтового ящика в целевую почтовую базу, параллельно запрашивая Data Guarantee API для определения состояния целевой инфраструктуры копий почтовых баз. Пока возвращаемый статус равен Satisfied, выполнение запроса на перемещение будет продолжаться.
• MRS выполняет начальную синхронизацию, создавая мгновенный снимок почтового ящика-источника и реплицируя его папки и содержимое. Во время этого процесса MRS запрашивает Data Guarantee API каждые 10 секунд, чтобы определить состояние целевой инфраструктуры копий почтовых баз. Пока возвращаемый статус равен Satisfied, выполнение запроса на перемещение будет продолжаться.
• MRS выполняет дополнительную синхронизацию, реплицируя изменения, появившиеся по отношению к первоначальному мгновенному снимку. Во время этого процесса MRS запрашивает Data Guarantee API каждые 10 секунд, чтобы определить состояние целевой инфраструктуры копий почтовых баз. Пока возвращаемый статус равен Satisfied, выполнение запроса на перемещение будет продолжаться.
• MRS блокирует почтовый ящик-источник.
• MRS выполняет дополнительную синхронизацию, чтобы провести изменения, сделанные с момента последнего события синхронизации, кроме того, копирует другие данные почтового ящика. Начиная Exchange 2010 SP1 MRS будет заставлять целевую базу применить активный транзакционный журнал, если он еще не применился, тем самым гарантируя, что непрерывная репликация может реплицировать информацию этого журнала, который содержит данные синхронизации перемещаемого почтового ящика. MRS определяет, выполнилось ли это успешно с помощью вызова Check Replication Flush в Data Guarantee API.
• MRS запрашивает Data Guarantee API, чтобы определить состояние инфраструктуры копий почтовых баз. Пока возвращаемый статус равен Satisfied, выполнение запроса на перемещение будет продолжаться.
• MRS обновляет учетную запись пользователя в Active Directory, отмечая, что перемещение завершено.
• MRS блокирует целевой почтовый ящик.
• MRS изменяет состояние почтового ящика в почтовой базе-источнике на soft-deleted. Эта функция была добавлена в Exchange 2010 SP1 для гарантии того, что в случае потери целевой почтовой базы вы сможете восстановить почтовый ящик из предыдущей почтовой базы.

Если во время шагов с 1 по 4 Data Guarantee API вернет NotSatisfied или Retry, MRS поместит запрос на перемещение в очередь и будет повторять запрос каждые 30 секунд. MRS помещает запрос на перемещение в очередь не более чем на 15 минут, после чего аварийного его завершает. Если в пределах этих 15 минут возвращается ответ Satisifed, MRS будет автоматически возобновлять запрос на перемещение.

Во время шага 6 MRS будет ждать максимум 30 минут, пока Data Guarantee API не вернет Satisfied (повторяя запрос каждые 10 секунд). Если Satisfied не получен, то MRS будет аварийно завершать перемещение почтового ящика.

Когда запрос на перемещение завершается аварийно, он не будет возобновляться сервисом MRS автоматически. До выполнения Resume-MoveRequest администратору следует выполнить Get-MoveRequestStatistics для того, чтобы определить причину аварийного завершения перемещения. После этого администратор может выполнить Resume-MoveRequest.

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

[/H1toH2]