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

Откуда:
Сообщений: 114
 		Denis,
При таком раскладе в помощь вам прокладка оптики до цода) Через интернет такие обьемы если только в асинхронном виде гонять.
18 янв 16, 15:15    [18696166]     Ответить | Цитировать Сообщить модератору
 Re: Синхронное зеркало, требование к каналу  [new]
Alibek B.
Member

Откуда:
Сообщений: 3873
Denis
Ну то есть для SQL это все равно, что нажали кнопку reset на сервере?

Нет. Если используются инструменты SAN, то они обеспечивают консистентность данных.
Только дорого это.
18 янв 16, 16:33    [18696856]     Ответить | Цитировать Сообщить модератору
 Re: Синхронное зеркало, требование к каналу  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10779
Блог
Denis
Александр Гладченко, А нет ли у вас каких-то материалов, которые показывают какие происходят потери производительности при каких условиях?


Не думаю, что стоит полагаться на общие рекомендации, лучше протестировать в максимально приближенных к вашим условиях. Много полезного могут сообщить метрики ожиданий, к примеру, одна из них исследуется тут: http://blogs.msdn.com/b/alwaysonpro/archive/2015/01/06/troubleshooting-data-latency-issues-on-alwayson-readable-secondary-replicas-due-to-slow-redo-or-redo-thread-contention.aspx
18 янв 16, 17:09    [18697216]     Ответить | Цитировать Сообщить модератору
 Re: Синхронное зеркало, требование к каналу  [new]
Denis
Member

Откуда: Russia, Moscow
Сообщений: 56
 		rootman,

Оптика так оптика, я так понимаю Вы говорите про оптику под IP сеть + AlwaysOn, а не под FC сеть и SAN репликацию?
И все таки в количественном выражении какие требования должны быть к каналу для AlwaysOn?
19 янв 16, 09:48    [18699703]     Ответить | Цитировать Сообщить модератору
 Re: Синхронное зеркало, требование к каналу  [new]
Denis
Member

Откуда: Russia, Moscow
Сообщений: 56
Александр Гладченко
Denis
Александр Гладченко, А нет ли у вас каких-то материалов, которые показывают какие происходят потери производительности при каких условиях?


Не думаю, что стоит полагаться на общие рекомендации, лучше протестировать в максимально приближенных к вашим условиях. Много полезного могут сообщить метрики ожиданий, к примеру, одна из них исследуется тут: http://blogs.msdn.com/b/alwaysonpro/archive/2015/01/06/troubleshooting-data-latency-issues-on-alwayson-readable-secondary-replicas-due-to-slow-redo-or-redo-thread-contention.aspx


Ок, спасибо.
Когда все уже построено можно провести тестирование и +/- сказать какую мы получили потерю производительности.
Но хотелось бы до того как начать строить, спроектировать с учетом +/- нужных требований к каналу.
19 янв 16, 09:52    [18699722]     Ответить | Цитировать Сообщить модератору
 Re: Синхронное зеркало, требование к каналу  [new]
Denis
Member

Откуда: Russia, Moscow
Сообщений: 56
Alibek B.
Denis
Ну то есть для SQL это все равно, что нажали кнопку reset на сервере?

Нет. Если используются инструменты SAN, то они обеспечивают консистентность данных.
Только дорого это.


Можете по подробнее рассказать?
Каким образом, инструменты SAN обеспечивают консистентность данных?
К сожалению практического опыта работы с такими инструментами я не имел, но изучая этот вопрос не нашел ответ как SAN может обеcпечить логическую целостность данных SQL?

ИМХО: проблема перехода на резервный диск - та же что при нажатии кнопки ресет: часть закомиченных транзакций не записалась в БД, а успела попасть только в журнал и при старте SQL на резервном узле БД будет в Recovery, и время пока она из него выйдет зависит от того на сколько длительные и массовые транзакции шли в момент сбоя.
В случае синхронного AlwaysOn в теории БД должна стать активной практически мгновенно, вне зависимости от объема и интенсивности транзакций в момент сбоя.
19 янв 16, 10:03    [18699760]     Ответить | Цитировать Сообщить модератору
 Re: Синхронное зеркало, требование к каналу  [new]
rootman
Member

Откуда:
Сообщений: 114
Denis
rootman,

Оптика так оптика, я так понимаю Вы говорите про оптику под IP сеть + AlwaysOn, а не под FC сеть и SAN репликацию?
И все таки в количественном выражении какие требования должны быть к каналу для AlwaysOn?

Так решение то комплексное) одно без другого работать не будет)
Какое решение выбирать это уже на ваше усмотрение. хотите OlwaysOn или SAN репликацию. Вопрос как всегда исключительно в бюджете. Если вы хотите построить HA + DR я на вашем месте рассмотрел бы вариант из 3-4 серверов. 2 на одной площадке, и асинхронное зеркалирование на удаленную. По толщине канала, могу сказать следующее, все зависит от количества зеркалируемых данных, даже если у вас будет мега маленький пинг, а толщина канала не большая, то при реорганизации индексов на базе с размером 20 ТБ все и закончится.
Как всегда все упирается в стоимость и нужность такого решения. Угрохать 100500$ и получить DR или потратить намного меньше и получить асинхронный DR с небольшим отставанием.
19 янв 16, 10:05    [18699765]     Ответить | Цитировать Сообщить модератору
 Re: Синхронное зеркало, требование к каналу  [new]
rootman
Member

Откуда:
Сообщений: 114
Denis
Alibek B.
пропущено...

Нет. Если используются инструменты SAN, то они обеспечивают консистентность данных.
Только дорого это.


Можете по подробнее рассказать?
Каким образом, инструменты SAN обеспечивают консистентность данных?
К сожалению практического опыта работы с такими инструментами я не имел, но изучая этот вопрос не нашел ответ как SAN может обеcпечить логическую целостность данных SQL?

ИМХО: проблема перехода на резервный диск - та же что при нажатии кнопки ресет: часть закомиченных транзакций не записалась в БД, а успела попасть только в журнал и при старте SQL на резервном узле БД будет в Recovery, и время пока она из него выйдет зависит от того на сколько длительные и массовые транзакции шли в момент сбоя.
В случае синхронного AlwaysOn в теории БД должна стать активной практически мгновенно, вне зависимости от объема и интенсивности транзакций в момент сбоя.

SAN обеспечивает целостность любых данных путем последовательного записывания данных на оба стродежа, т.е. приходят данные на стредж№1 с помощью внутренних инструментов отправляются на сторедж№2, и любое приложение котрое отправила данные на запись не получит подтверждения записи до тех пор пока сторедж№1 не получит подтверждения от сторедж№2 о том что он получил и записал данные которые были ему отправлены.
19 янв 16, 10:09    [18699783]     Ответить | Цитировать Сообщить модератору
 Re: Синхронное зеркало, требование к каналу  [new]
Alibek B.
Member

Откуда:
Сообщений: 3873
rootman
SAN обеспечивает целостность любых данных путем последовательного записывания данных на оба стродежа

Мы говорим о разных вещах.
Целостность файлов обеспечивается в любом случае.
Но промышленные СХД также обеспечивают и консистентность данных приложения (а не целостность файлов). Разумеется не любых приложений, а тех, чья поддержка заявлена, но такие СУБД как MSSQL или Oracle поддерживаются.
19 янв 16, 11:04    [18700039]     Ответить | Цитировать Сообщить модератору
 Re: Синхронное зеркало, требование к каналу  [new]
Alibek B.
Member

Откуда:
Сообщений: 3873
Denis
Можете по подробнее рассказать?
Каким образом, инструменты SAN обеспечивают консистентность данных?
К сожалению практического опыта работы с такими инструментами я не имел, но изучая этот вопрос не нашел ответ как SAN может обеcпечить логическую целостность данных SQL?

Не могу, потому что с БД не работал и таких практических задач не возникала.
Но промышленная СХД имеется и представители разработчика рассказывали, что такой инструмент имеется и обкатан.
Как я понял, на СХД приобретается специальная лицензия и/или фича, плюс на сервера СУБД устанавливается специальный компонент, и в результатами СХД может работать не с сырыми байтами, а умеет различать объекты приложения.
Я бы посоветовал связаться с вендором (мне о такой возможности рассказывали Fujitsu и NetApp) и спросить у них, за спрос денег не берут. У Фуджитсу сейлы технически довольно подготовленные и при необходимости легко подключают нужных технических специалистов. У NetApp все чуть более формализовано, но и они дадут развернутый ответ.
19 янв 16, 11:10    [18700088]     Ответить | Цитировать Сообщить модератору
 Re: Синхронное зеркало, требование к каналу  [new]
rootman
Member

Откуда:
Сообщений: 114
Alibek B.
rootman
SAN обеспечивает целостность любых данных путем последовательного записывания данных на оба стродежа

Мы говорим о разных вещах.
Целостность файлов обеспечивается в любом случае.
Но промышленные СХД также обеспечивают и консистентность данных приложения (а не целостность файлов). Разумеется не любых приложений, а тех, чья поддержка заявлена, но такие СУБД как MSSQL или Oracle поддерживаются.

Видимо вы вот про такое http://www8.hp.com/h20195/V2/getpdf.aspx/4AA4-3941ENW.pdf?ver=1.0
19 янв 16, 11:24    [18700168]     Ответить | Цитировать Сообщить модератору
 Re: Синхронное зеркало, требование к каналу  [new]
Ferdipux
Member

Откуда: Москва
Сообщений: 587
 		[quot Alibek B.]
Denis
Можете по подробнее рассказать?
...
Я бы посоветовал связаться с вендором (мне о такой возможности рассказывали Fujitsu и NetApp)...

За Fujitsu не скажу, разбирался с работой такой штуки в NetApp.
Есть несколько средств обеспечить целостность файлов БД.
  • Группа целостности. Вы объявляете несколько дисков как одну группу целостности, и при репликации на другой СХД идет sync - копия при операции на любом из дисков. Цель - обеспечить целостность группы связанных приложений, например, OLTP и DWH-OLAP над ней (который забирает данные из OLTP).
  • Адаптер для приложения. Интегрируется в приложение, SSMS и позволяет использовать дополнительные возможности СХД, например, моментальные снимки, при осуществлении бекапов и восстановлений.

    Штука интересная, но ничего волшебного она не делает.
    • 19 янв 16, 11:27    [18700187]     Ответить | Цитировать Сообщить модератору
     Re: Синхронное зеркало, требование к каналу  [new]
    Alibek B.
    Member

    Откуда:
    Сообщений: 3873
         		С продуктами HP не знаком, но по описанию похоже.
    Правда подход вроде бы отличается, но конечная задача одна и та же, целостность данных БД.
    19 янв 16, 11:28    [18700198]     Ответить | Цитировать Сообщить модератору
     Re: Синхронное зеркало, требование к каналу  [new]
    rootman
    Member

    Откуда:
    Сообщений: 114
    Alibek B.
    С продуктами HP не знаком, но по описанию похоже.
    Правда подход вроде бы отличается, но конечная задача одна и та же, целостность данных БД.

    Тогда логично искать ответ про канал на сайтах производителей СХД, притом как я понял из документа HP то и alwaysON то же завязан на стродже, и к сиквелу уже мало отношения имеет.
    19 янв 16, 11:32    [18700227]     Ответить | Цитировать Сообщить модератору
     Re: Синхронное зеркало, требование к каналу  [new]
    alexeyvg
    Member

    Откуда: Moscow
    Сообщений: 31816
    Denis
    ИМХО: проблема перехода на резервный диск - та же что при нажатии кнопки ресет: часть закомиченных транзакций не записалась в БД, а успела попасть только в журнал и при старте SQL на резервном узле БД будет в Recovery, и время пока она из него выйдет зависит от того на сколько длительные и массовые транзакции шли в момент сбоя.
    В случае синхронного AlwaysOn в теории БД должна стать активной практически мгновенно, вне зависимости от объема и интенсивности транзакций в момент сбоя.
    При выключении сервера, даже при синхронном AlwaysOn, всё равно текущая транзакция будет откатываться.
    Другое дело, что старт будет быстрее; видимо, не будет такой большой прокачки кеша. Но кеш скомпилированных запросов всё равно должен заполняться.
    ИМХО преимуществ в скорости подъёма у синхронного AlwaysOn не будет, преимущества только в том, что точно не будет потерянных последних транзакций.
    19 янв 16, 12:35    [18700664]     Ответить | Цитировать Сообщить модератору
     Re: Синхронное зеркало, требование к каналу  [new]
    Гавриленко Сергей Алексеевич
    Member

    Откуда: Moscow
    Сообщений: 37198
    Denis
    В случае синхронного AlwaysOn в теории БД должна стать активной практически мгновенно, вне зависимости от объема и интенсивности транзакций в момент сбоя.
    Путаете теплое с мягким. Синхронный AlwaysOn гарантирует, что в логи всех реплик будет записана вся транзакция и commit (про rollback, например, не уверен), но не гарантирует, что при записи commit весь лог на реплике будет применен. Т.е. реплики у вас могут быть Synchronized, на при этом на вторичной реплике может быть воот такая очередь на Redo, и при failover вы сразу попадаете на Recovery, соразмерный по времени рамеру очереди на Redo.

    Именно поэтому я вам очень не рекомендую начинать эксплуатацию AlwaysOn с включенным автоматическим faiolver.

    Сообщение было отредактировано: 19 янв 16, 12:56
    19 янв 16, 12:55    [18700791]     Ответить | Цитировать Сообщить модератору
     Re: Синхронное зеркало, требование к каналу  [new]
    Гавриленко Сергей Алексеевич
    Member

    Откуда: Moscow
    Сообщений: 37198
         		Забыл сказать. Стандартная процедура Recovery (вернее, вторая ее фаза) почему-то заметно медленнее, чем Redo в AlwaysOn. Поэтому что бы делать failover на реплику с большой очередью, надо иметь веские причины.
    19 янв 16, 13:03    [18700830]     Ответить | Цитировать Сообщить модератору
     Re: Синхронное зеркало, требование к каналу  [new]
    Александр Гладченко
    Member

    Откуда:
    Сообщений: 10779
    Блог
    Denis
    Александр Гладченко
    пропущено...


    Не думаю, что стоит полагаться на общие рекомендации, лучше протестировать в максимально приближенных к вашим условиях. Много полезного могут сообщить метрики ожиданий, к примеру, одна из них исследуется тут: http://blogs.msdn.com/b/alwaysonpro/archive/2015/01/06/troubleshooting-data-latency-issues-on-alwayson-readable-secondary-replicas-due-to-slow-redo-or-redo-thread-contention.aspx


    Ок, спасибо.
    Когда все уже построено можно провести тестирование и +/- сказать какую мы получили потерю производительности.
    Но хотелось бы до того как начать строить, спроектировать с учетом +/- нужных требований к каналу.


    Всё будет зависеть от характера и объёма тиражируемых на зеркало транзакций. Особенно сложно вам будет такое просчитать, если у вас "микс" из разного типа запросов, не только OLTP, но и "долгоиграющие" - в таком разе всё станет ещё более непредсказуемым.
    В общем, если вам удастся "обрести" алгоритм расчёта требований - не забудьте с нами поделиться :)
    Мы поступили просто, канал проложили такой толщины, какая была максимально возможна. Это не очень дорого ;) Однако, далеко не каждая база зеркалировалась, и дело было не в каналах. В основном, проблем не возникало с не большими базами, до 30Тб, у которых характер запросов близкий к OLTP.
    19 янв 16, 13:44    [18701106]     Ответить | Цитировать Сообщить модератору
     Re: Синхронное зеркало, требование к каналу  [new]
    Denis
    Member

    Откуда: Russia, Moscow
    Сообщений: 56
         		Гавриленко Сергей Алексеевич, Спасибо! Честно говоря, был уверен что при failover, БД спокойно переедет на зеркало со своим redo логом и никакого recovery не будет (мы говорим именно про синхронное зеркало). Я еще потестирую этот момент, но если Вы правы, то это печалька.

    Коллеги, всем кто откликнулся, спасибо за участие! Если решение будет таки построено обязательно отпишу о результатах.
    19 янв 16, 18:31    [18702854]     Ответить | Цитировать Сообщить модератору
     Re: Синхронное зеркало, требование к каналу  [new]
    Denis
    Member

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

    Всё будет зависеть от характера и объёма тиражируемых на зеркало транзакций. Особенно сложно вам будет такое просчитать, если у вас "микс" из разного типа запросов, не только OLTP, но и "долгоиграющие" - в таком разе всё станет ещё более непредсказуемым.
    В общем, если вам удастся "обрести" алгоритм расчёта требований - не забудьте с нами поделиться :)
    Мы поступили просто, канал проложили такой толщины, какая была максимально возможна. Это не очень дорого ;) Однако, далеко не каждая база зеркалировалась, и дело было не в каналах. В основном, проблем не возникало с не большими базами, до 30Тб, у которых характер запросов близкий к OLTP.


    Александр, я правильно понял, что вы строили синхронное зеркало с БД порядка 30 ТБ?
    А что было при пересчете индексов/статистик?

    Из моего опята нагрузка на сервер, особенно если считать индексы/статистики в несколько потоков, значительно превышает все, что могут потребовать от сервера пользователи. Это должно быть самым сильным испытанием для синхронного зеркала.
    19 янв 16, 18:36    [18702866]     Ответить | Цитировать Сообщить модератору
     Re: Синхронное зеркало, требование к каналу  [new]
    Гавриленко Сергей Алексеевич
    Member

    Откуда: Moscow
    Сообщений: 37198
    Denis
    А что было при пересчете индексов/статистик?
    При ребилде индексов ничего хорошего не было. Поэтому мы не ребилдим больше индексы...
    19 янв 16, 19:50    [18703043]     Ответить | Цитировать Сообщить модератору
     Re: Синхронное зеркало, требование к каналу  [new]
    Александр Гладченко
    Member

    Откуда:
    Сообщений: 10779
    Блог
         		Denis,
    Реплики у нас асинхронные, без чтения. Когда технология будет зрелой, попробуем читать :)
    19 янв 16, 22:06    [18703400]     Ответить | Цитировать Сообщить модератору
     Re: Синхронное зеркало, требование к каналу  [new]
    Denis
    Member

    Откуда: Russia, Moscow
    Сообщений: 56
    Гавриленко Сергей Алексеевич
    Denis
    А что было при пересчете индексов/статистик?
    При ребилде индексов ничего хорошего не было. Поэтому мы не ребилдим больше индексы...


    А пересчет статистик?
    или фулскан не используете?
    19 янв 16, 23:03    [18703556]     Ответить | Цитировать Сообщить модератору
     Re: Синхронное зеркало, требование к каналу  [new]
    o-o
    Guest
    Denis
    Гавриленко Сергей Алексеевич
    пропущено...
    При ребилде индексов ничего хорошего не было. Поэтому мы не ребилдим больше индексы...


    А пересчет статистик?
    или фулскан не используете?

    граждане крутые дядьки с не менее крутыми СХД, простите ради бога за вмешательство.
    но дело в том, что за вчера на форуме уже было 2 недвусмысленных намека,
    типа пересчет статистики ЛОГ РАЗДУВАЕТ.
    вы все в курсе моей неуемной фантазии, но вот не хватает мне ее в данном случае.
    подскажите, плиз,
    что же именно идет в лог при пересчете статистики,
    что аж ALWAYS ON загибается?
    т.е. я понимаю, что сейчас в моде делать подобные заявления,
    но одно дело, когда это мигель1 выступает, и другое дело такая крутая компашка...

    К сообщению приложен файл. Размер - 22Kb
    19 янв 16, 23:56    [18703691]     Ответить | Цитировать Сообщить модератору
     Re: Синхронное зеркало, требование к каналу  [new]
    Гавриленко Сергей Алексеевич
    Member

    Откуда: Moscow
    Сообщений: 37198
         		o-o,

    Мы статистику не пересчитываем, поэтому в моих постах как бы речь _только_ про ребилд.

    Но, btw, пересчет статистики по своей сути -- считать много, и запихать это "много" в маааленькую такую гистограмму. Откуда возьмется нагрузка на лог, не понятно.

    Сообщение было отредактировано: 20 янв 16, 02:42
    20 янв 16, 02:41    [18703859]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: ←Ctrl  назад   1 [2] 3   вперед  Ctrl→      все
    Все форумы / Microsoft SQL Server Ответить