Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
AlwaysOn на Windows Server Failover Cluster и его listener: понимание концепции
|
|||
|---|---|---|---|
|
#18+
Здравствуйте, один из моих учителей сказал мне, что можно утверждать о понимании концепции, только если можешь ее объяснить кому угодно, и он поймет. Так вот, у меня в понимании технологии AlwaysOn есть один существенный пробел. Listener В начале все вроде бы ясно: 1. За отказ оборудования на физическом уровне отвечает Windows Cluster 2. За отказ сервиса SQL AlwaysOn 3. Все экземпляры Sql Server для использования AlwaysOn должны быть установлены на узлах одного кластера (не котроллера домена) 4. Создание группы AlwaysOn 4. Далее: создание Listner. Вот тут у меня пробел. Что есть в сущности listener? По документации это "network connectivity endpoint". По определению endpoint это устройство. Это физическое устройство? или запись в ActiveDirectory создается автоматически при создании listener и IP (statico) не соответствует никакому реальному "железу" (то есть вводится любой свободный адрес)? То есть, пока жив сервер ActiveDirectory жив и listener? Таким образом, правильно ли будет сказать, что при отказе железа произойдет автоматическое переключение на следующий сервер и AlwaysOn в случае автоматического переключения сделает вторичную реплику активной? А если IP listener соответствует или является алиасом первичного сервера SQL на котором отказало железо? Что произойдет? Windows произведет переключение на следующий узел, а AlwaysOn? Будет ли он доступен? Будет ли возможность вручную активировать вторичную реплику? Буду благодарна за ответы и поправки ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2018, 18:17 |
|
||
|
AlwaysOn на Windows Server Failover Cluster и его listener: понимание концепции
|
|||
|---|---|---|---|
|
#18+
Eugenia, 2. За отказ сервиса SQL AlwaysOn - нет, за отказ отвечает кластерная службы RHS, которая чекая периодически службу SQL Что есть в сущности listener? - это объект кластреной службы AlwaysOn, к которой привязаны параметры, такие как объекты в DNS, IP авторТаким образом, правильно ли будет сказать, что при отказе железа произойдет автоматическое переключение на следующий сервер и AlwaysOn в случае автоматического переключения сделает вторичную реплику активной? - не всегда, если у AlwaysOn стоит проверять Healt баз данных, тогда да перейдет Failover, из железа произодет Failover, если железо косвенно связано с кластерной службой. Если у вас вышел диск или сетка , которые никак не влияют на кластерные службы, то Failover -а не будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2018, 19:09 |
|
||
|
AlwaysOn на Windows Server Failover Cluster и его listener: понимание концепции
|
|||
|---|---|---|---|
|
#18+
авторТаким образом, правильно ли будет сказать, что при отказе железа произойдет автоматическое переключение на следующий сервер и AlwaysOn в случае автоматического переключения сделает вторичную реплику активной? Верно, но только в случае если выполняются требования для automatic failover (SYNCHRONIZED, quorum итд). Кстати это касается не только отказа железа (где помогает Heartbeat), но и проблем с сервисом и внутренние ошибки Sql Server(Lease Timeout, Sql Server Resource.dll), а с 2016 проблемы с бд (точнее с ее статусом). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2018, 20:29 |
|
||
|
AlwaysOn на Windows Server Failover Cluster и его listener: понимание концепции
|
|||
|---|---|---|---|
|
#18+
Eugenia, 2. За отказ сервиса SQL - как уже писали, отвечает подсистема размещения ресурсов кластера (RHS), тк служба SQL реализует AG как ресурсные группы WSFC. И, если случается, что время аренды ресурса превышает допустимый порог, то это повод для failover. Listener (DNS name + static IP) - ресурс кластера и им владеет одна из AG и куда уедет эта AG туда и listener. Физически listener это IP, который сажается на один из сетевых интерфейсов активной ноды - ноды, содержащей первичную реплику AG (см ipconfig /all на активной ноде). И да, имя + IP прописываются а AD-е, на что УЗ кластера нужны соответствующие права. И AD-контроллеров должно быть несколько, что б не постигла печаль. Про failover level в инете тонны статей, там некоторая настройка в виде 5-и уровней, каждый из которых реагирует на определенный набор событий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.10.2018, 00:02 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=39605707&tid=1688974]: |
0ms |
get settings: |
6ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
30ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
36ms |
get tp. blocked users: |
2ms |
| others: | 216ms |
| total: | 313ms |

| 0 / 0 |
