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

Откуда:
Сообщений: 22
как я понимаю на практике доставка журналов транзакций не поможет?
21 мар 13, 14:42    [14077493]     Ответить | Цитировать Сообщить модератору
 Re: отказоустойчивость сервера SQL  [new]
fna55
Member

Откуда:
Сообщений: 22
в принципе стоит задача "выноса" данных из основного цод в резервный.. пусть даже с потерей за последние 10-15мин и временем на переключения до 15 мин
21 мар 13, 14:45    [14077507]     Ответить | Цитировать Сообщить модератору
 Re: отказоустойчивость сервера SQL  [new]
Glory
Member

Откуда:
Сообщений: 104760
fna55
как я понимаю на практике доставка журналов транзакций не поможет?

Вы сначала определитесь с
- бюджетом
- требованием ко времени переключения
- режимом работы резервного сервера
21 мар 13, 14:47    [14077528]     Ответить | Цитировать Сообщить модератору
 Re: отказоустойчивость сервера SQL  [new]
fna55
Member

Откуда:
Сообщений: 22
бюджет - в 2-цод уже есть сервера на которых установлен sql, поэтому в идеале решить все уже имеющимися средствами...
2 - хочется найти золоту середину между производительностью и переносом данных...
21 мар 13, 14:51    [14077550]     Ответить | Цитировать Сообщить модератору
 Re: отказоустойчивость сервера SQL  [new]
Glory
Member

Откуда:
Сообщений: 104760
fna55
бюджет - в 2-цод уже есть сервера на которых установлен sql

Бюджет - это деньги. например, на покупку нужной редакции/версии сервера или оборудования.
21 мар 13, 14:53    [14077563]     Ответить | Цитировать Сообщить модератору
 Re: отказоустойчивость сервера SQL  [new]
rahzer
Member

Откуда:
Сообщений: 2297
автор
в принципе стоит задача "выноса" данных из основного цод в резервный.. пусть даже с потерей за последние 10-15мин и временем на переключения до 15 мин

Для начала, стоит создать хотя бы 1 (свой основной) надежный ЦОД, что подразумевает задублированность серверов, наличие системы хранения данных (с двумя контроллерами, резервными связями с локальными серверами), питания (2 ИБП), охлаждения.
Дальше, уже думаете, где у Вас второй ЦОД - либо свой, либо в арендованный облаках (если это позволительно политикой компании).
Свой ЦОД хотя бы 1 надо сделать нормально, чтобы не оправдываться потом. а вот видите мы переключились на резервный, не зря платим или деньги вкладываем, Это все равно потери времени, которые оборачиваются в деньги, дерготня пользователей и админов.
Поэтому укрепляете первый рубеж, дальше второй и т.п (либо синхронное построение рубежей). Это классика построения катастрофоустойчивых решений.
21 мар 13, 14:54    [14077571]     Ответить | Цитировать Сообщить модератору
 Re: отказоустойчивость сервера SQL  [new]
rahzer
Member

Откуда:
Сообщений: 2297
Урежьте связь программным путем у резервного сервера до 10Мб или сколько там у Вас, а лучше даже и меньше, потому что у вас то они соединены через 1 свич или напрямую, а там путь будет длиньше, задержек больше, так что еще будут потери, так же подумать, что будет, если канала не будет (а неприятности любят сыпаться все сразу), либо тех работы у прова, либо кабель перебили, а может какой-нить глобальный транстелеком заглючил. Вот и сэмулируете резервное переключение в теории, посмотрите как и что.
Лично я бы начал с добавкой в существующий ЦОД СХД, и 2-го ИБП, если его нет, получится уже ближе к истине.
Тестировали на VMWare и бюджетной СХД и двух серверах, просто обесточивали один хост (на горячую вырубали питание), терялся только один пакет, все сервисы благополучно переезжали за мгновение на другой хост.
21 мар 13, 15:04    [14077644]     Ответить | Цитировать Сообщить модератору
 Re: отказоустойчивость сервера SQL  [new]
fna55
Member

Откуда:
Сообщений: 22
ребята, мне сейчас более актуально как реализовать обмен между цод... нежли внутри...
21 мар 13, 15:08    [14077670]     Ответить | Цитировать Сообщить модератору
 Re: отказоустойчивость сервера SQL  [new]
rahzer
Member

Откуда:
Сообщений: 2297
автор
ребята, мне сейчас более актуально как реализовать обмен между цод...

Идея то какая? Отказоустойчивость? иди от малого к большому, сначала основной ЦОД выстрой, как следует, потом берись за резервный, а то получишь киш-миш, вроде что-то есть, а нифига не работает..
Вот навернулся ИБП, коротыш произошел или обесточило серверную - через какие коммутаторы у тебя канал работать будет?
Ладно, есть резервный ЦОД, а канал до него не задублирован, по каким то причинам (технически оборудование упало, пьяный экскаваторщик перебил линию) - нет канала и что?
Простое - снять часть облака (если политика позволяет) и пользоваться в случае чего. Либо сервак перенести в другое место. Я уже говорил, скорость внутри у себя между ними ограничь, выставь одному жестко 10Мб и отруби основной жестко, а потом попробуй перенести - будешь видеть.
В одной мировой компании, где я работал, жестко - приезжает комиссия, заходят с уполномоченными в серверную, отрубают все, засекают время и смотрят на действия админов, на восстановление работоспособности и сравнивают с SLA
А по программным средствам тебе вроде говорили уже, нет?
21 мар 13, 15:26    [14077795]     Ответить | Цитировать Сообщить модератору
 Re: отказоустойчивость сервера SQL  [new]
Glory
Member

Откуда:
Сообщений: 104760
fna55
более актуально как реализовать обмен между цод

Вам уже предлагали
- mirroring
- replication
- log shipping
- failover cluster
Вы уже прочитали про требования и возможности каждого из методов и выбрали тот, который подходит вам больше всего
21 мар 13, 15:27    [14077804]     Ответить | Цитировать Сообщить модератору
 Re: отказоустойчивость сервера SQL  [new]
fna55
Member

Откуда:
Сообщений: 22
я же писал, что хочу услышать так сказать мнение людей которые на практике реализовывали... в книжках то красиво пишут
21 мар 13, 15:30    [14077828]     Ответить | Цитировать Сообщить модератору
 Re: отказоустойчивость сервера SQL  [new]
Glory
Member

Откуда:
Сообщений: 104760
fna55
что хочу услышать так сказать мнение людей которые на практике реализовывали..

Зачем вам рассказывать про failover cluster, если вы не собираетесь тратиться на это решение ?
21 мар 13, 15:31    [14077841]     Ответить | Цитировать Сообщить модератору
 Re: отказоустойчивость сервера SQL  [new]
fna55
Member

Откуда:
Сообщений: 22
почему не собираюсь... тратиться... я ищу оптимальное решение и высказываю пожелание реализовать на базе уже развернутого оборудования
21 мар 13, 15:40    [14077922]     Ответить | Цитировать Сообщить модератору
 Re: отказоустойчивость сервера SQL  [new]
fna55
Member

Откуда:
Сообщений: 22
давайте вопрос поставим по другому, здесь есть кто своими руками настраивал "доставку журналов" сежду 2-мя географически удалёнными серверами?
21 мар 13, 15:42    [14077939]     Ответить | Цитировать Сообщить модератору
 Re: отказоустойчивость сервера SQL  [new]
Glory
Member

Откуда:
Сообщений: 104760
fna55
я ищу оптимальное решение

Критерии оптимальности имеют математическое воплащение.
Вы вашу оптимальность как измеряете ?
21 мар 13, 15:43    [14077948]     Ответить | Цитировать Сообщить модератору
 Re: отказоустойчивость сервера SQL  [new]
fna55
Member

Откуда:
Сообщений: 22
оптимальность - это потеря данных максимум 10 мин и "дублирование" данных не сильно влияет на производительность
21 мар 13, 15:46    [14077973]     Ответить | Цитировать Сообщить модератору
 Re: отказоустойчивость сервера SQL  [new]
fna55
Member

Откуда:
Сообщений: 22
почитав литературу я для себя определил что вроде подходит именно Доставка журналов - только хотел услышать "практиков" (уже устал это повторять)
21 мар 13, 15:59    [14078072]     Ответить | Цитировать Сообщить модератору
 Re: отказоустойчивость сервера SQL  [new]
Maxx
Member [скрыт]

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

LogShipping на даст быстро поднять его в боевой режим (резеврный сервер ,да и обратное переключение ролей тоже поребует труда) :( Мирроринг ,имхо,больше подходит для вашей задачи
21 мар 13, 16:01    [14078089]     Ответить | Цитировать Сообщить модератору
 Re: отказоустойчивость сервера SQL  [new]
LogrusAS
Member

Откуда: Киев
Сообщений: 195
rahzer
Тестировали на VMWare и бюджетной СХД и двух серверах, просто обесточивали один хост (на горячую вырубали питание), терялся только один пакет, все сервисы благополучно переезжали за мгновение на другой хост.


А с каких пор SQL сервер нормально работает на одном ядре?
Или спрошу по другому, с каких пор VMWare поддерживает резервацию для виртуальных машин с более чем одним виртуальным процессором?

Работа это не только пинги, как любят на демонстрациях показывать продавцы VMWare.



А по сути вопроса - пробуйте логшиппинг или мироринг. Именно пробуйте.
И то и то ответ на вопрос.
А вот КАК настроить, боюсь никто на форуме не поможет. Либо спецов вызывайте, либо пробуйте.
21 мар 13, 16:01    [14078100]     Ответить | Цитировать Сообщить модератору
 Re: отказоустойчивость сервера SQL  [new]
Glory
Member

Откуда:
Сообщений: 104760
fna55
оптимальность - это потеря данных максимум 10 мин и "дублирование" данных не сильно влияет на производительность

Т.е. переключение серверов может хоть неделю идти ? Главное, чтобы от момента сбоя данные не были потеряны более чем на 10минут назад ?
21 мар 13, 16:03    [14078116]     Ответить | Цитировать Сообщить модератору
 Re: отказоустойчивость сервера SQL  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
LogrusAS
Или спрошу по другому, с каких пор VMWare поддерживает резервацию для виртуальных машин с более чем одним виртуальным процессором?


Да вообще,помоему,давненько
21 мар 13, 16:04    [14078124]     Ответить | Цитировать Сообщить модератору
 Re: отказоустойчивость сервера SQL  [new]
LogrusAS
Member

Откуда: Киев
Сообщений: 195
fna55
почитав литературу я для себя определил что вроде подходит именно Доставка журналов - только хотел услышать "практиков" (уже устал это повторять)


Зависит от версии сервера.

По сути мироринг в асинхронном режиме (а именно такой и нужно поднять в случае удаленных площадок) не сильно отличается от доставки журналов. Это развитие идеи доставки журналов.

Но более автоматизированое.
В случае доставки, после падения, Вам будет нужно руками на резервном сервере поднять последний бекап журнала, перелитый самой процедурой. С включением режима боевой базы. Размеров Ваших мы не знаем, но думаю за 15 минут поднять можно.

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

Можно и в автомате сделать, но тогда режим синхронный нужен, а в Вашем случае не рекомендую.

Ну и версия сервера какая?
Может там 2000 и мироринга нет вообще?
21 мар 13, 16:09    [14078166]     Ответить | Цитировать Сообщить модератору
 Re: отказоустойчивость сервера SQL  [new]
fna55
Member

Откуда:
Сообщений: 22
т.е. на практике ни кто такую задачу не решал?
21 мар 13, 16:11    [14078186]     Ответить | Цитировать Сообщить модератору
 Re: отказоустойчивость сервера SQL  [new]
Glory
Member

Откуда:
Сообщений: 104760
fna55
т.е. на практике ни кто такую задачу не решал?

Конечно нет. Вы первый за последние -нцать лет существования баз данных.
21 мар 13, 16:12    [14078193]     Ответить | Цитировать Сообщить модератору
 Re: отказоустойчивость сервера SQL  [new]
LogrusAS
Member

Откуда: Киев
Сообщений: 195
Maxx
LogrusAS
Или спрошу по другому, с каких пор VMWare поддерживает резервацию для виртуальных машин с более чем одним виртуальным процессором?


Да вообще,помоему,давненько


Думал, может я протупил. И быстренько побежал включать на своей VMWare 5.1 со всеми последними обновлениями.
И вот что мне ответили:
A-BOOT
The Fault Tolerance configuration of the entity A-BOOT has an issue: The virtual
machine has more than one virtual CPU.


Может разъясните чего я не так делаю?
21 мар 13, 16:13    [14078204]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить