Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Always On как альтернатива кластеру SQL  [new]
flexgen
Member

Откуда: Город на песке
Сообщений: 782
Возник следующий вопрос - может ли Always on быть использован как альтернатива кластеру SQL? Мне подобная идея кажется неудачной. Но на нас давят системщики, в свете поголовной виртуализации всего и вся. Они утверждают что кластер, а точнее распределенные между нодами диски, не позволяют в полной мере использовать новые фичи VMWare, например vmotion. Приводили еще какие-то аргументы, связанные с апгрейдами самого хост-сервера. У кого-нибудь имеется опыт замены HA cluster на Always on? И каковы результаты?
24 окт 14, 00:41    [16751752]     Ответить | Цитировать Сообщить модератору
 Re: Always On как альтернатива кластеру SQL  [new]
NickAlex66
Member

Откуда:
Сообщений: 319
flexgen,

А виртуальный SQL кластер тоже не устраивает?
24 окт 14, 00:49    [16751774]     Ответить | Цитировать Сообщить модератору
 Re: Always On как альтернатива кластеру SQL  [new]
flexgen
Member

Откуда: Город на песке
Сообщений: 782
NickAlex66
flexgen,

А виртуальный SQL кластер тоже не устраивает?


Меня вполне устраивает, а вот системщикам он мешает. Как я уже писал, главный аргумент - невозможность использовать vmotion.
24 окт 14, 01:12    [16751808]     Ответить | Цитировать Сообщить модератору
 Re: Always On как альтернатива кластеру SQL  [new]
Crimean
Member

Откуда:
Сообщений: 13148
так по идее AO не хуже, а местами еще и "лучше", чем кластер. почему вдруг "Мне подобная идея кажется неудачной"?
24 окт 14, 10:32    [16752499]     Ответить | Цитировать Сообщить модератору
 Re: Always On как альтернатива кластеру SQL  [new]
Виталий Перевозчиков
Member

Откуда:
Сообщений: 40
AlwaysOn ничем не хуже кластера, местами даже лучше, например можно использовать дешевые дискове массивы. У себя настраивали (в виртуализации), все работало, единственное с чем нужно было заморачиваться - это синхронизация логинов и заданий между серверами, также при тестировании всплыл тот факт, что при отработке отказа прозрачность переключения для sql-логинов не обеспечивается (нужно делать reconnect).
24 окт 14, 11:00    [16752711]     Ответить | Цитировать Сообщить модератору
 Re: Always On как альтернатива кластеру SQL  [new]
Crimean
Member

Откуда:
Сообщений: 13148
Виталий Перевозчиков
при отработке отказа прозрачность переключения для sql-логинов не обеспечивается (нужно делать reconnect).


а вы НЕ используете конекшен пулы? тогда да, реконнект по любому чиху
24 окт 14, 11:27    [16752871]     Ответить | Цитировать Сообщить модератору
 Re: Always On как альтернатива кластеру SQL  [new]
Виталий Перевозчиков
Member

Откуда:
Сообщений: 40
Crimean,

если Вы про эти пулы соединения http://msdn.microsoft.com/ru-ru/library/8xx3tyca(v=vs.110).aspx
то если я правильно понял, это настраивается в коде приложения?
24 окт 14, 11:40    [16752969]     Ответить | Цитировать Сообщить модератору
 Re: Always On как альтернатива кластеру SQL  [new]
Crimean
Member

Откуда:
Сообщений: 13148
Виталий Перевозчиков,

вы можете _запретить_ пулинг. и "просто" работать с коннектом. тогда будет "паттерн"
Open
...
Execute
Execute
Execute
...
Close
и при таком паттерне вы "попадаете" на кучу проблем

или разрешать пулинг и работать так:

...
Open
Execute
Close
...
Open
Execute
Close
...
Open
Execute
Close
...

и вот тут у вас проблем будет на порядок меньше. а ре-логонов - поверьте и проверьте - не будет :)
24 окт 14, 11:53    [16753073]     Ответить | Цитировать Сообщить модератору
 Re: Always On как альтернатива кластеру SQL  [new]
Виталий Перевозчиков
Member

Откуда:
Сообщений: 40
Crimean,
Спасибо за информацию, приму к сведению, но дело в том что все приложения, которые мы используем покупные и изменять их код мы не имеем возможности.
24 окт 14, 11:57    [16753095]     Ответить | Цитировать Сообщить модератору
 Re: Always On как альтернатива кластеру SQL  [new]
flexgen
Member

Откуда: Город на песке
Сообщений: 782
Crimean
так по идее AO не хуже, а местами еще и "лучше", чем кластер. почему вдруг "Мне подобная идея кажется неудачной"?


Меня немного смущает конфигурация, которая подразумевает наличие двух независимых инстансов с двумя разными наборами баз данных. Плюс у меня на трех кластерах приблизительно 400 пользовательских баз, не станет ли количесто баз проблемой при синхронизации?
24 окт 14, 15:19    [16754456]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить