Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Топик располагается на нескольких страницах: ←Ctrl назад 1 [2] 3 вперед Ctrl→ все |
fna55 Member Откуда: Сообщений: 22 |
как я понимаю на практике доставка журналов транзакций не поможет? |
21 мар 13, 14:42 [14077493] Ответить | Цитировать Сообщить модератору |
fna55 Member Откуда: Сообщений: 22 |
в принципе стоит задача "выноса" данных из основного цод в резервный.. пусть даже с потерей за последние 10-15мин и временем на переключения до 15 мин |
21 мар 13, 14:45 [14077507] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Вы сначала определитесь с - бюджетом - требованием ко времени переключения - режимом работы резервного сервера |
||
21 мар 13, 14:47 [14077528] Ответить | Цитировать Сообщить модератору |
fna55 Member Откуда: Сообщений: 22 |
бюджет - в 2-цод уже есть сервера на которых установлен sql, поэтому в идеале решить все уже имеющимися средствами... 2 - хочется найти золоту середину между производительностью и переносом данных... |
21 мар 13, 14:51 [14077550] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Бюджет - это деньги. например, на покупку нужной редакции/версии сервера или оборудования. |
||
21 мар 13, 14:53 [14077563] Ответить | Цитировать Сообщить модератору |
rahzer Member Откуда: Сообщений: 2297 |
Для начала, стоит создать хотя бы 1 (свой основной) надежный ЦОД, что подразумевает задублированность серверов, наличие системы хранения данных (с двумя контроллерами, резервными связями с локальными серверами), питания (2 ИБП), охлаждения. Дальше, уже думаете, где у Вас второй ЦОД - либо свой, либо в арендованный облаках (если это позволительно политикой компании). Свой ЦОД хотя бы 1 надо сделать нормально, чтобы не оправдываться потом. а вот видите мы переключились на резервный, не зря платим или деньги вкладываем, Это все равно потери времени, которые оборачиваются в деньги, дерготня пользователей и админов. Поэтому укрепляете первый рубеж, дальше второй и т.п (либо синхронное построение рубежей). Это классика построения катастрофоустойчивых решений. |
||
21 мар 13, 14:54 [14077571] Ответить | Цитировать Сообщить модератору |
rahzer Member Откуда: Сообщений: 2297 |
Урежьте связь программным путем у резервного сервера до 10Мб или сколько там у Вас, а лучше даже и меньше, потому что у вас то они соединены через 1 свич или напрямую, а там путь будет длиньше, задержек больше, так что еще будут потери, так же подумать, что будет, если канала не будет (а неприятности любят сыпаться все сразу), либо тех работы у прова, либо кабель перебили, а может какой-нить глобальный транстелеком заглючил. Вот и сэмулируете резервное переключение в теории, посмотрите как и что. Лично я бы начал с добавкой в существующий ЦОД СХД, и 2-го ИБП, если его нет, получится уже ближе к истине. Тестировали на VMWare и бюджетной СХД и двух серверах, просто обесточивали один хост (на горячую вырубали питание), терялся только один пакет, все сервисы благополучно переезжали за мгновение на другой хост. |
21 мар 13, 15:04 [14077644] Ответить | Цитировать Сообщить модератору |
fna55 Member Откуда: Сообщений: 22 |
ребята, мне сейчас более актуально как реализовать обмен между цод... нежли внутри... |
21 мар 13, 15:08 [14077670] Ответить | Цитировать Сообщить модератору |
rahzer Member Откуда: Сообщений: 2297 |
Идея то какая? Отказоустойчивость? иди от малого к большому, сначала основной ЦОД выстрой, как следует, потом берись за резервный, а то получишь киш-миш, вроде что-то есть, а нифига не работает.. Вот навернулся ИБП, коротыш произошел или обесточило серверную - через какие коммутаторы у тебя канал работать будет? Ладно, есть резервный ЦОД, а канал до него не задублирован, по каким то причинам (технически оборудование упало, пьяный экскаваторщик перебил линию) - нет канала и что? Простое - снять часть облака (если политика позволяет) и пользоваться в случае чего. Либо сервак перенести в другое место. Я уже говорил, скорость внутри у себя между ними ограничь, выставь одному жестко 10Мб и отруби основной жестко, а потом попробуй перенести - будешь видеть. В одной мировой компании, где я работал, жестко - приезжает комиссия, заходят с уполномоченными в серверную, отрубают все, засекают время и смотрят на действия админов, на восстановление работоспособности и сравнивают с SLA А по программным средствам тебе вроде говорили уже, нет? |
||
21 мар 13, 15:26 [14077795] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Вам уже предлагали - mirroring - replication - log shipping - failover cluster Вы уже прочитали про требования и возможности каждого из методов и выбрали тот, который подходит вам больше всего |
||
21 мар 13, 15:27 [14077804] Ответить | Цитировать Сообщить модератору |
fna55 Member Откуда: Сообщений: 22 |
я же писал, что хочу услышать так сказать мнение людей которые на практике реализовывали... в книжках то красиво пишут |
21 мар 13, 15:30 [14077828] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Зачем вам рассказывать про failover cluster, если вы не собираетесь тратиться на это решение ? |
||
21 мар 13, 15:31 [14077841] Ответить | Цитировать Сообщить модератору |
fna55 Member Откуда: Сообщений: 22 |
почему не собираюсь... тратиться... я ищу оптимальное решение и высказываю пожелание реализовать на базе уже развернутого оборудования |
21 мар 13, 15:40 [14077922] Ответить | Цитировать Сообщить модератору |
fna55 Member Откуда: Сообщений: 22 |
давайте вопрос поставим по другому, здесь есть кто своими руками настраивал "доставку журналов" сежду 2-мя географически удалёнными серверами? |
21 мар 13, 15:42 [14077939] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Критерии оптимальности имеют математическое воплащение. Вы вашу оптимальность как измеряете ? |
||
21 мар 13, 15:43 [14077948] Ответить | Цитировать Сообщить модератору |
fna55 Member Откуда: Сообщений: 22 |
оптимальность - это потеря данных максимум 10 мин и "дублирование" данных не сильно влияет на производительность |
21 мар 13, 15:46 [14077973] Ответить | Цитировать Сообщить модератору |
fna55 Member Откуда: Сообщений: 22 |
почитав литературу я для себя определил что вроде подходит именно Доставка журналов - только хотел услышать "практиков" (уже устал это повторять) |
21 мар 13, 15:59 [14078072] Ответить | Цитировать Сообщить модератору |
Maxx Member [скрыт] Откуда: Сообщений: 24290 |
fna55, LogShipping на даст быстро поднять его в боевой режим (резеврный сервер ,да и обратное переключение ролей тоже поребует труда) :( Мирроринг ,имхо,больше подходит для вашей задачи |
21 мар 13, 16:01 [14078089] Ответить | Цитировать Сообщить модератору |
LogrusAS Member Откуда: Киев Сообщений: 195 |
А с каких пор SQL сервер нормально работает на одном ядре? Или спрошу по другому, с каких пор VMWare поддерживает резервацию для виртуальных машин с более чем одним виртуальным процессором? Работа это не только пинги, как любят на демонстрациях показывать продавцы VMWare. А по сути вопроса - пробуйте логшиппинг или мироринг. Именно пробуйте. И то и то ответ на вопрос. А вот КАК настроить, боюсь никто на форуме не поможет. Либо спецов вызывайте, либо пробуйте. |
||
21 мар 13, 16:01 [14078100] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Т.е. переключение серверов может хоть неделю идти ? Главное, чтобы от момента сбоя данные не были потеряны более чем на 10минут назад ? |
||
21 мар 13, 16:03 [14078116] Ответить | Цитировать Сообщить модератору |
Maxx Member [скрыт] Откуда: Сообщений: 24290 |
Да вообще,помоему,давненько |
||
21 мар 13, 16:04 [14078124] Ответить | Цитировать Сообщить модератору |
LogrusAS Member Откуда: Киев Сообщений: 195 |
Зависит от версии сервера. По сути мироринг в асинхронном режиме (а именно такой и нужно поднять в случае удаленных площадок) не сильно отличается от доставки журналов. Это развитие идеи доставки журналов. Но более автоматизированое. В случае доставки, после падения, Вам будет нужно руками на резервном сервере поднять последний бекап журнала, перелитый самой процедурой. С включением режима боевой базы. Размеров Ваших мы не знаем, но думаю за 15 минут поднять можно. В случае с мирорингом почти то же самое. Но нужно зайти в свойства базы и включить ее в режим основной. Вот обратно будет немного сложнее. Но тоже можно сделать. Необходимое время - подключиться и нажать кнопку. Потери - не закрытые транзакции. В общем их будет меньше, чем с доставкой журналов. Можно и в автомате сделать, но тогда режим синхронный нужен, а в Вашем случае не рекомендую. Ну и версия сервера какая? Может там 2000 и мироринга нет вообще? |
||
21 мар 13, 16:09 [14078166] Ответить | Цитировать Сообщить модератору |
fna55 Member Откуда: Сообщений: 22 |
т.е. на практике ни кто такую задачу не решал? |
21 мар 13, 16:11 [14078186] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Конечно нет. Вы первый за последние -нцать лет существования баз данных. |
||
21 мар 13, 16:12 [14078193] Ответить | Цитировать Сообщить модератору |
LogrusAS Member Откуда: Киев Сообщений: 195 |
Думал, может я протупил. И быстренько побежал включать на своей VMWare 5.1 со всеми последними обновлениями. И вот что мне ответили: A-BOOT Может разъясните чего я не так делаю? |
||||
21 мар 13, 16:13 [14078204] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: ←Ctrl назад 1 [2] 3 вперед Ctrl→ все |
Все форумы / Microsoft SQL Server | ![]() |