Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Применение зеркалирования для вопросов масштабирования, повышения проивзодительности.  [new]
Дедушка
Member

Откуда: Город трёх революций
Сообщений: 5122
с alwayson к сожалению приходится сильно дороже платить только за синхронную базу для чтения.
у меня сложилось впечатление, что это некий промежуточный шаг к чему то другому.
1 ноя 12, 18:02    [13410636]     Ответить | Цитировать Сообщить модератору
 Re: Применение зеркалирования для вопросов масштабирования, повышения проивзодительности.  [new]
Crimean
Member

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

написал на мыло...
1 ноя 12, 18:32    [13410731]     Ответить | Цитировать Сообщить модератору
 Re: Применение зеркалирования для вопросов масштабирования, повышения проивзодительности.  [new]
МуМу
Member

Откуда:
Сообщений: 1134
Потестили немного режим alwayson. Выводы следующие:
База в режиме readonly - т.е. использовать для балансировки уже можно.
Транзакции синхронны, пишутся вместе. Пишется и на источнике и на зеркале синхронно в журналы транзакций. Проверить легко - данные не появляются(select c nolock) пока не пройдет комит. С другой стороны как только он появляется - даже огроменная транзакция накатывается моментально.Изменения идут на низком уровне.(в профайлере и т.п. явно конструкций не видно)Издержки точно есть в случае большого количества маленьких транзакций. (в разы дольше) Пока не совсем понятно как обеспечивается эффективная многопоточность. Очевидно что данные пишутся в транскашин лог на зеркале. Но также очевидно что они должны писаться в таком же порядке как и на основном сервере. Каким образом это достигается пока не ясно.(есть только предположения) В целом пока что очень понравилось. Никто не подскажет сколько все это в комплексе будет стоить? Я имею ввиду что например нужно разворачивать windows cluster.(тоже вопрос, нафига? какоим он боком к зеркалированию?)
12 ноя 12, 20:23    [13461392]     Ответить | Цитировать Сообщить модератору
 Re: Применение зеркалирования для вопросов масштабирования, повышения проивзодительности.  [new]
Дедушка
Member

Откуда: Город трёх революций
Сообщений: 5122
МуМу
windows cluster тоже вопрос, нафига? какоим он боком к зеркалированию?
потому как это не зеркалирование, а именно кластер (высокой доступности) который обеспечивает связь узлов и переезд служб.
МуМу
Никто не подскажет сколько все это в комплексе будет стоить?
прикиньте сами...
- минимум 3 сервера (при этом дешёвым как для витнеса при зеркалировании не обойдётесь) +
- лицензии на ОС соответствующей редакции +
- лицензии на SQL Server соответствующей редакции +
- в каждый сервер по паре HBA (достаточной пропускной способности) +
- обвязка для fibre channel +
- дисковое хранилище (и начальным уровнем не обойдётесь ибо контроллеры станут узким местом)
а теперь прикидываем ROI...
ИМХО, для очень узкого круга задач.
13 ноя 12, 10:39    [13463063]     Ответить | Цитировать Сообщить модератору
 Re: Применение зеркалирования для вопросов масштабирования, повышения проивзодительности.  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10802
Блог
МуМу,

А кластер нужен настоящий, или достаточно на одном сервере развернуть, а зеркало в кластер не включать?
13 ноя 12, 10:39    [13463070]     Ответить | Цитировать Сообщить модератору
 Re: Применение зеркалирования для вопросов масштабирования, повышения проивзодительности.  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10802
Блог
Дедушка
МуМу
windows cluster тоже вопрос, нафига? какоим он боком к зеркалированию?
потому как это не зеркалирование, а именно кластер (высокой доступности) который обеспечивает связь узлов и переезд служб.


Я всё равно не понял, чем кластер зеркалированию помогает? ...у меня подозрение, что только для создания AG...
13 ноя 12, 10:43    [13463092]     Ответить | Цитировать Сообщить модератору
 Re: Применение зеркалирования для вопросов масштабирования, повышения проивзодительности.  [new]
M0rpheus
Member

Откуда:
Сообщений: 14
Дедушка
МуМу
Никто не подскажет сколько все это в комплексе будет стоить?
прикиньте сами...
- минимум 3 сервера (при этом дешёвым как для витнеса при зеркалировании не обойдётесь) +
- лицензии на ОС соответствующей редакции +
- лицензии на SQL Server соответствующей редакции +
- в каждый сервер по паре HBA (достаточной пропускной способности) +
- обвязка для fibre channel +
- дисковое хранилище (и начальным уровнем не обойдётесь ибо контроллеры станут узким местом)
а теперь прикидываем ROI...
Возможен и несколько более дешевый вариант, все зависит от требуемой производительности:
Failover Windows Cluster
- 2 сервера + разделяемый файловый ресурс на любом из существующих на предприятии серверов Windows
- 2 лицензии на ОС соответствующей редакции
- 2 сетевых адаптера в каждом сервере (ну или по одному 2х-портовому)
- общее дисковое хранилище не обязательно
SQL AlwaysOn
- 2 лицензии на SQL Server соответствующей редакции
- 2 комплекта (RAID-контроллер + внешняя дисковая полка) для расположения баз AG на каждом сервере

По сравнению с зеркалированием в такой же конфигурации получаем плюсы в виде использования ресурсов второго сервера для readonly нагрузки, бэкапов + ручной или автоматический файловер. Ну и в случае написания приложений с использованием соединения с AG Listener (если он нужен) "маршрутизацию" соединений таких приложений, в том числе и для режима ReadOnly.

Дедушка
ИМХО, для очень узкого круга задач.
ИМХО, ввиду такой конфигурации и стоимости, конечно же не для бухучета в 1С на предприятии из 25 человек.
Хотя смотря что они там учитывают :-)
13 ноя 12, 12:00    [13463694]     Ответить | Цитировать Сообщить модератору
 Re: Применение зеркалирования для вопросов масштабирования, повышения проивзодительности.  [new]
M0rpheus
Member

Откуда:
Сообщений: 14
Александр Гладченко
Я всё равно не понял, чем кластер зеркалированию помогает? ...у меня подозрение, что только для создания AG...
Насколько я на данный момент понимаю, именно для AG и файловера между узлами AG (AG как раз и прописывается в типах ресурсов кластера Windows и публикуется как приложение/сервис).
13 ноя 12, 12:06    [13463741]     Ответить | Цитировать Сообщить модератору
 Re: Применение зеркалирования для вопросов масштабирования, повышения проивзодительности.  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10802
Блог
M0rpheus,

Т.е. кластер может быть не полный? ...меня интересует возможность резервного копирования с зеркала, и с минимальными затратами :)
13 ноя 12, 12:10    [13463777]     Ответить | Цитировать Сообщить модератору
 Re: Применение зеркалирования для вопросов масштабирования, повышения проивзодительности.  [new]
Дедушка
Member

Откуда: Город трёх революций
Сообщений: 5122
Александр Гладченко
Т.е. кластер может быть не полный?
что значит "не полный"?
13 ноя 12, 12:17    [13463850]     Ответить | Цитировать Сообщить модератору
 Re: Применение зеркалирования для вопросов масштабирования, повышения проивзодительности.  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10802
Блог
Дедушка,

Один узел.
13 ноя 12, 12:23    [13463911]     Ответить | Цитировать Сообщить модератору
 Re: Применение зеркалирования для вопросов масштабирования, повышения проивзодительности.  [new]
Дедушка
Member

Откуда: Город трёх революций
Сообщений: 5122
первичная БД и ридонли не могут быть на одном узле
13 ноя 12, 12:30    [13463971]     Ответить | Цитировать Сообщить модератору
 Re: Применение зеркалирования для вопросов масштабирования, повышения проивзодительности.  [new]
Дедушка
Member

Откуда: Город трёх революций
Сообщений: 5122
M0rpheus
Возможен и несколько более дешевый вариант, все зависит от требуемой производительности
автор рассматривает alwayson не в плане доступности а в плане производительности... поэтому имхо ваш вариант не пройдёт по параметрам (да и не сильно он дешевле)
к тому же собирать кластер без общего дискового? ну не знаю...
а 2 узла будет только если отказываемся от перехода по файловеру.
13 ноя 12, 12:37    [13464027]     Ответить | Цитировать Сообщить модератору
 Re: Применение зеркалирования для вопросов масштабирования, повышения проивзодительности.  [new]
M0rpheus
Member

Откуда:
Сообщений: 14
Александр Гладченко,

В требованиях MS для создания AG указывается "Ensure that each computer is a node in a Windows Server Failover Clustering (WSFC) cluster". Честно говоря попробовать создавать AG без создания кластера мне в голову чего-то не пришло даже :-) Так что думаю для реализации того, что Вы хотите получить, надо будет минимальный комплект (на мой взгляд) собирать, который я выше описывал. Разве что за минусом "- 2 комплекта (RAID-контроллер + внешняя дисковая полка) для расположения баз AG на каждом сервере", если дисковые подсистемы у Вас справляются.
P.S. постоянно просматриваю Ваш блог (отдельное спасибо за тамошние публикации), так там такая информация излагается которая лично до меня часто доходит далеко не с первого прочтения, поэтому не думаю что организация кластера Windows для Вас составляет какую-то сложность :-) Из каких соображений его организовать-то не хочется? Видимо чего-то я не уловил.
13 ноя 12, 12:38    [13464039]     Ответить | Цитировать Сообщить модератору
 Re: Применение зеркалирования для вопросов масштабирования, повышения проивзодительности.  [new]
M0rpheus
Member

Откуда:
Сообщений: 14
Дедушка
M0rpheus
Возможен и несколько более дешевый вариант, все зависит от требуемой производительности
автор рассматривает alwayson не в плане доступности а в плане производительности... поэтому имхо ваш вариант не пройдёт по параметрам (да и не сильно он дешевле)
к тому же собирать кластер без общего дискового? ну не знаю...
а 2 узла будет только если отказываемся от перехода по файловеру.

И чем без общего дискового не кластер? Опять же почему отказываемся от перехода по файловеру?
2 узла + сетевая шара - в полностью рабочем варианте один сервер основной, второй для ридонли и бэкапов (вот производительность, а не только доступность). При выходе одного сервера из строя кластер Windows живой по кворуму, самом собой на период восстановления "умершего" сервера вся нагрузка на оставшийся ложится. Я бы предпочел кластер из 4-х узлов но с дисковыми ресурсами для базы на каждом узле, чем n-кратно защищенный общий диисковый массив, который может являться единой точкой отказа (имел "удовольствие" такое наблюдать).
Ну тут наверно дело вкуса :-)
13 ноя 12, 12:46    [13464105]     Ответить | Цитировать Сообщить модератору
 Re: Применение зеркалирования для вопросов масштабирования, повышения проивзодительности.  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10802
Блог
M0rpheus,

У меня зеркало в другом датацентре сейчас живёт, туда же DPM забирает файлы резервных копий. Канал между датацентрами не резиновый, хотел за счёт возможности делать копии с зеркала его разгрузить. ...iSCSI не хотелось бы использовать, только ради кластера, который мне не нужен...
13 ноя 12, 12:53    [13464184]     Ответить | Цитировать Сообщить модератору
 Re: Применение зеркалирования для вопросов масштабирования, повышения проивзодительности.  [new]
МуМу
Member

Откуда:
Сообщений: 1134
Я рассматриваю кластер в первую очередь с точки зрения повышения производительности. А только во вторую очередь как довесок с точки зрения резервирования.
Теперь по пунктам. Считаю что общее дисковое хранилище не нужно. Как раз оно может стать узким местом. В данном случае как раз вопрос синхронизации данных выполняет SQL синхронно записывая их журналы транзакций. Сеть - да действительно может стать узким местом. Но fibre channel в большинстве случаев будет излишеством. Для синхронного режима важнее латентность сети. Но современный езернет уже обеспечивает достаточную латенсность да и инфинибанд уже стоит не так много. То есть хватит за глаза 10GB езернет. А вообще нужнго смотреть на систему, сколько транзакций к СУБД в секунду. Важно именно транзакции потому как именно они передаются по каналу между зеркалом и источником. А запросы на чтение - пойдут по отдельному каналу.(шина не станет узким местом, а если и станет то извините на одном сервере такая система сразу умрет)
Все равно не понимаю зачем для данного режима виндоус кластер?(у нас без него не развернулось) Только для решения вопросов отказоустойчивости? Но они все решаемы административно! А вот синхронное зеркалирование в режиме readonly так просто не решается. Я вижу пока только маркетинговую состовляющую.
13 ноя 12, 13:07    [13464303]     Ответить | Цитировать Сообщить модератору
 Re: Применение зеркалирования для вопросов масштабирования, повышения проивзодительности.  [new]
M0rpheus
Member

Откуда:
Сообщений: 14
Александр Гладченко,
Значит в данном случае не Ваш вариант, насколько я понимаю...
13 ноя 12, 13:11    [13464341]     Ответить | Цитировать Сообщить модератору
 Re: Применение зеркалирования для вопросов масштабирования, повышения проивзодительности.  [new]
Дедушка
Member

Откуда: Город трёх революций
Сообщений: 5122
M0rpheus
Опять же почему отказываемся от перехода по файловеру?
я понял :) вы про AG на отдельных инстансах, а я из контекста предположил, что разговор про кластерный вариант.
в таком варианте, да возможно.
13 ноя 12, 13:45    [13464712]     Ответить | Цитировать Сообщить модератору
 Re: Применение зеркалирования для вопросов масштабирования, повышения проивзодительности.  [new]
МуМу
Member

Откуда:
Сообщений: 1134
Написал статью на тему масштабируемости с применением кластеров(не апаратных). Внедрял у клиентов на транзакционной репликации, давно работало хоть и не эффективно на логшипинге.
Сейчас активно исследуем SQL 2012 always on, на подходе тесты по нагрузочному тестированию (пока стенд достойный раздобыть не можем). Как только будут результаты , сразу выложу.
Разработали свой прототип кластера с принципиально другим подходом чем в зеркалировании. Запросы на изменение дублируются на несколько серверов одновременно , при этом обеспечивается высокая многопоточность и единая хронология выполнения операций. Теоретически если выстрелит, будет очень интересное решение.
Вот статья, еще не причесанная. Цифры графики и примеры будут чуть позже.
http://softpoint.ru/article_id4221.htm
14 ноя 12, 18:34    [13474206]     Ответить | Цитировать Сообщить модератору
 Re: Применение зеркалирования для вопросов масштабирования, повышения проивзодительности.  [new]
МуМу
Member

Откуда:
Сообщений: 1134
Активно занимаюсь сейчас вопросом адаптации always on под различные ИТ системы. Интересные факты выясняются. Например то что синхронность кластера не такая уж и синхронная. Выполняя в цикле update таблицы в цикле и сразу же после комита считывая через линкед сервер есть шанс поймать еще старые данные.(микросекунды) То же самое реализованное через один коннект не позволяет добиться подобной ситуации.
Возникают два вопроса. Насколько выполняется условие двухфазной фиксации транзакции?
Это важно для резервирования например. Какие могут быть потенциально задержки?
Эксперименты проводятся но уже сейчас могу выскаазать предположение. Скорее всего существует координатор который фиксирует последовательно две транзакции. На основном сервере и на зеркале-ах. Вопрос только в том что судя по всему он не дожидается фиксации на зеркале(возможно по вопросам производительности). Несмотря на то что пишет в транзакшен логи параллельно все равно может возникнуть небольшой интервал между фиксацией (comit) на основном сервере и на зеркале. Соответсвенно если в этот момент отключится основной сервер - транзакция может потеряться.(не смотря на то что она есть в транзакшион логе, фиксация то не прошла) Как это проверить наверняка? Читать напрямую данные с помощью логреадера. Также есть еще один потенциальный риск. Я сталкивался пару раз когда данные в MSSQL разрушались на низком уровне.(решалось чекдб обычно) Ну например в уникальном иднексе появлялись неуникальные значения. В этом случае тоже может произойти рассинхронизация кластера. Хотя это конечно очень маловероятно.
Насчет задержки(при комитах) сейчас проводим дополнительные нагрузочные тесты. Как будет более подробная информация напишу.
23 ноя 12, 11:42    [13517988]     Ответить | Цитировать Сообщить модератору
 Re: Применение зеркалирования для вопросов масштабирования, повышения проивзодительности.  [new]
_SiMBA_
Member

Откуда: Almaty
Сообщений: 157
Добрый день.

Есть какие либо новости по нагрузочным тестам ?

Тоже собираемся внедрять AlwaysOn
Базы весьма большие. Нужно для распределения нагрузки и синхронность не особо важна, если вопрос синхронизации не занимает часы... конечно.

Есть вопросы
Насколько большой трафик между серверами, можно ли его посчитать хотябы в теории если известен прирост базы в объеме в сутки
Потянет ли эта технология базы 1-4Тб
Можно ли держать зеркало РО на линиях связи 100мегабит

В ближайшее время займемся тестами... но если есть информация о граблях заранее, было бы здорово.
14 янв 13, 18:02    [13768591]     Ответить | Цитировать Сообщить модератору
 Re: Применение зеркалирования для вопросов масштабирования, повышения проивзодительности.  [new]
_SiMBA_
Member

Откуда: Almaty
Сообщений: 157
Поигрался с AlwaysOn в тестовой среде на древнем железе.

С виду весьма живучая группа, перезагрузки, апдейты и патчи на любую из нод, даже развал рейда (правда с востановлением) выдерживает неплохо и собирается обратно после включения инстанса.
Сегодня померил трафик по сети, между нодами, гдето 3 к 1, т.е. инсертил табличку в 14 гигов, на секондари пролилось 4.7 гига.
Утилизация канала составила 20-60 мегабит.
28 янв 13, 16:35    [13840452]     Ответить | Цитировать Сообщить модератору
 Re: Применение зеркалирования для вопросов масштабирования, повышения проивзодительности.  [new]
МуМу
Member

Откуда:
Сообщений: 1134
Надеюсь совсем скоро дадут оборудование. У нас тесты несколько другого рода. Трафик не интересует, так как другие задачи решаются.
Трафик по моим предположениям будет пропорционален(а может и практически равен) приросту журнала транзакций. Можно его померять и сравнить с трафиком. Также в таком контексте возникает вопрос, а можно ли трафик архивировать? Наверняка он хорошо сживается только вот с точки зрения производительности вряд ли такую возможность предусматривали разработчики.
28 янв 13, 17:46    [13840862]     Ответить | Цитировать Сообщить модератору
 Re: Применение зеркалирования для вопросов масштабирования, повышения проивзодительности.  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
МуМу
Надеюсь совсем скоро дадут оборудование. У нас тесты несколько другого рода. Трафик не интересует, так как другие задачи решаются.
Трафик по моим предположениям будет пропорционален(а может и практически равен) приросту журнала транзакций. Можно его померять и сравнить с трафиком. Также в таком контексте возникает вопрос, а можно ли трафик архивировать? Наверняка он хорошо сживается только вот с точки зрения производительности вряд ли такую возможность предусматривали разработчики.
Смысла жать траффик особого нет, так как все как всегда тупо упрется в последовательное применение этого журнала на репликах.
28 янв 13, 17:50    [13840881]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить