Pull to refresh

Comments 36

«Не имея, до недавнего времени, подобного профита» — wat
Возможно имелось ввиду другое иноземное слово «экспирианс».
Т.е. слово «опыт» отменили… Как всё быстро летит ^_^
Там в двух предложениях подряд получилось бы слово «опыт».
Экспирианс тоже ничего, но профит на ум быстрей пришло.
Слово как слово…
I weep for the future of IT.
И, да, как сказали ниже, с сертификатами что-то перемудрили. Т.е. дисбаланс какой-то технологический вышел: подняли простенькое зеркало, но с использованием сертификатов. Зачем? Чем обусловлен выбор?
И хотелось бы побольше дополнительной информации: что за база, размеры, какова нагруженность, тип нагрузки (транзакции или хранилище данных), что «получилось» потерять при обрушении мастера, замеряли ли трафик между серверами при зеркалировании, зачем вообще зеркалирование сделали. А то получилось какое-то зеркалирование ради зеркалирования и мануал который гуглится за 10 минут. :\
Почему простенький? Обычное зеркало. С сертификатами мне показалось более изящное решение. Не каких регламентных требований не было установлено, я сделал сертификаты :-) Базы master были идентичные, так что после переключения клиентов проблем в общем-то не было. Вы можете назвать много причин для зеркалирования, кроме обеспечения отказоустойчивости? Трафик, там незначительно увеличился, потому как ижет передача журнала физически плюс сжатие, в отличие от той же репликации, я до работы доберусь могу скинуть значаний если интересно.
>Почему простенький?
Потому что вы не вдавались в подробности. Не сообщили параметры защищаемой БД, не описали почему был выбран этот вариант для повышения отказоустойчивости и даже не потрудились накидать схемку для иллюстрации топологии решения и как зеркалирование поможет в повышении этой самой отказоустойчивости в ваших условиях (Одним зеркалированием ведь дело не ограничивается, в смысле, вот принципал упал, теперь у вас есть зеркало на другом сервере — и что? Смогут его юзеры использовать?). Не рассказали про дополнительные параметры зеркалирования, просто тут по-дефолту, там по-дефолту, пока работает, миссия выполнена. Поэтому и выглядит ваша работа как зеркалирование ради зеркалирования от нечего-делать и вряд ли кому-то будет полезно, поскольку невозможно сравнить ситуации.

Решение с использованием сертификатов не изящное. Оно накладыват определённые ограничения, ответственность и увеличивает стоимость поддержки из-за необходимости их периодического обновления (а если ещё и не задокументировано должным образом, то может обернуться неприятным сюрпризом для следующего человека, которому достанется обслуживание инфраструктуры). Обычно оно применяется когда серверы находятся в разных доменах или вообще разнесены географически.
Можно ещё смайл обсудить в конце повествования.
Кстати, срок действия сертификатов по умолчанию — год, что может стать неприятным сюрпризом. И настройка для Windows Authentication немного проще — позволяет первые три пункта сделать через UI.
Ну можно дату начала действия и конца действия указать (START_DATE, EXPIRY_DATE).
А вообще да, можно и так и так кому как нравится.
>кому как нравится
Are you f*ckin' kiddin' me? Решение о выборе варианта фейловера для БД принимается на основе личных предпочтений администратора? Это плохой сон. Ущипните меня Т_Т
Метода авторизации в регламентах прописано не было, почему бы не принять решение самому. Быстродействию, безопасности от использования сертификатов хуже ведь не делается.
аутентификация притормаживает быстродействие
Аутентификация для mirroring endpoint в любом случае будет, но она же на скорость работы установленного соединения не влияет. Может притормаживать шифрование, но оно задается отдельной опцией.
правильно, но аутентификация происходит при каждом обращении одной базы к другой и в результате обращения проишодит обмен сертификатами. Вот этот обмен и проверка сертификата и притормаживает. Это происходит быстро но на общее время у нас мелкие задержки. Это некритично при малом количестве транзакций.
Это как в примере:
аутентификация Ты кто? — Я Вася, а пароль? — Пупкин, Проходи…
аутентификация с проверкой сертификата: Ты кто? -Я Вася, а пароль? — Пупкин, Номер паспорта? — 2344241313131232, Подожди я проверю если номер совпадает… Слышь? У тебя с номером все в порядке, проходи…
Ну пример может не совсем так показывает общую картину но думаю что идея понятна.
Идея понятна, но где подтверждение, хоть одной ссылкой?

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

Аутентификация происходит при установлении соединения, один раз, это явно сказано в msdn.microsoft.com/en-us/library/ms186360.aspx: Connection requests from a partner or witness, if any, must be authenticated.

Соединения устанавливается один раз, при старте первой сессии. Попробуйте настроить зеркала для нескольких баз и сделать выборку из sys.dm_db_mirroring_connections. Соединения постоянные, никуда не пропадают. Из описания dmv тоже достаточно очевидно, что аутентификация — часть connection handshake, а не самого протокола передачи транзакций.
«Are you f*ckin' kiddin' me?» — говорите вам слово «профит» не угодило??
Моя фраза означает «вы что, бл*дь, шутите?» и органично вписывается в контекст моего комментария. Слово «профит» означает «выгода» — и либо я не понял, что вы хотели сказать, либо вы не знали значения слова.
а разве администратор не отдает предпочтение чему либо? есть администраторы которые действуют только по книжке и выделенный текст скопируют правым кликом мышки и есть котоым хочется драйва после истечения срока сертификата…
я сервер установил один раз, соединил диски через LVM и все… прошли месяцы а то и года и даже забыл как LVM делается и через несколько лет чуствую себя плохим специалистом ибо уже не помню как то или то делается потому что работает и не падает, тогда как другие знают все команды и многое другое ибо делают по принципу как нравится. Это падает, он поднимает или делает заново, опять падает, опять поднимает и так выучивает все наизусть…
Отдаёт, я отдал предпочтение срок действия же разный можно прописать. Принципиальной разницы-то нету кроме личных предпочтений (если это предпочтения компании).
Предпочтение должно быть обоснованным, потому что если что-то важное упадёт, и компания потеряет время/деньги, то начнут разбираться, почему оно упало, и здесь может быть 2 продолжения истории: либо всё было сделано объективно правильно и виновато недостаточное финансирование, тогда ура, играемся с новыми серваками и железом; либо админ применил сомнительные и далеко не оптимальные решения, руководствуясь своими «предпочтениями», тут уже всё может стать куда мрачнее вплоть до увольнения, а потом долгих поисков работы, куда бы приняли с таким-то отзывом с предыдущего места.
это если мы говорим о компании с определённым количеством спецов в ИТ отделе, где есть и начальник отдела и все действия согласуются с ним. Если говорим о мелких или средних фирмах где отдел подчиняется шефу фирмы и где каждый ИТшник сам по себе то там так и происходит — каждый из них выбирает то ему больше понравилось. Нередко есть фирмы где «ИТ» менеджер понятия не имеет что ему обьясняет админ. Или фирма где админ и есть начальник отдела и крутит-вертит всё как ему захочется. Вводит в заблуждение или в страх руководство компании себе в выгоду. Меня так и наняли на работу ибо у руководства были большие сомнения насчет ихнего «ИТ» отдела. В результате: главный админ уволен ибо то что он построил было сделанно наспех и чтобы работало и он свято верил что данная архитектура и применяемый софт то что доктор прописал. Потом со временем сокращен отдел с 7 до 3 работников — ибо нефиг столько алкашей держать в штатах (куда молодежь катиться?). И радикально изменена ИТ инфраструктура. Зато как сложно было это сделать с 24х7 активно используемой пользователями системой да еще так чтобы сами не заметили изменений.
И все потому что никто кроме начальника отдела (админа) не понимал ни черта из того что он всем впихивал.
Ну вот, видите: админ работал по предпочтениям — теперь уволен. Всё сходится ^_^
Просто тут все в большом маштабе происходило и видать где-то он запутался а кто-то запомнил что он раньше сказал. А тут админ сертификацию по принципу «кому как нравиться» поставил. Выше я дал как бы пример что большинство админов/програмистов работают по данному принципу.
И даже это может обернуться серьёзными потерями, ситуация: админ поставил аутентификацию по сертификату, год всё работало и никто зеркало не трогал, вдруг обрушился принципал-сервер, админ тянется к зеркалу — а оно не обновлялось 3 недели. Почему? А сертификат протух и этого никто не заметил (и не заметят с таким-то уровнем, уверяю вас). Кто виноват?/Что делать?
>>сертификат протух и этого никто не заметил (и не заметят с таким-то уровнем, уверяю вас).
>>Кто виноват?
Ответственный за:
а) мониторинг
б) бэкапы
в) исполнение процедур

>>Что делать?
а) делать мониторинг и следить за тем что он выдаёт
б) следить за актуальностью и восстановимостью бэкапов (и не говорите мне что миррореная база не бэкап, и что бэкап на мастере должен лежать только на этом же сервере)
в) прописывать процедуры и тщательно им следовать, в том числе и:
1) проверка валидности сертификатов
2) ведение календаря временных сущностей
3) инструкция по обновлению сертификатов и запуску зеркалирования в т.ч. с нуля.

Если кто-то делает на «авось» (и в данном случае это не админ, а руководство, которое не желая понимать что БП на 99,9% зависим от IT не тратит на него деньги) — то тут ничего для предотвращения сбоя не поможет (не протухнут сертификаты — так харды повылетают, или учетки протухнут по паролю если им не меняют вовремя пароль\не стоит «без срока действия»\новый админ решит «усилить безопасность» и ВСЕМ учёткам поставит «требовать смену пароля») — а виноват будет человек который поднимал.
Согласен! Нужны настроенные уведомления о резервных копиях, о сбоях в работе серверов, в том числе зеркалировании (с этим только разбираюсь, если кто умеет за совет буду признателен), бэкапы разнесенные хотя бы по серверам. Существует корпоративная база знаний, дальнейшая работа будет вестись в соответствие с описанием от туда.
Сравнение по-принципу «Черный это цвет и белый это цвет — значит чёрно-белый телевизор цветной».
Не вижу проблемы! Сделал авторизацию по сертификатам, описал структуру в корпоративной базе знаний. Все вкурсе. Вам нравится виндовая авторизация — дерзайте! В тексте приложена ссылка как сделать зеркалирование с их использованием через GUI.
Защищённый с автоматическим восстановлением требует для автоматического восстановления использовать 3-й сервер (следящий) и в принципе полезен только если у вас в приложении можно указать резервный сервер для переключения в случае когда не работает основной.

Ну в общем-то резервный сервер далеко не всегда надо прописывать...msdn:Using Database Mirroring Да и «засирание информационного пространства следящим сервером» странная аргументация. Можно ведь использовать любой уже имеющийся в сети SQL Server, в т.ч. Express (ну, естественно, кроме тех, которые уже участвуют в этой сессии зеркалирования).

Это если Native Client для подключения используется. Туда тоже надо прописывать.
На сколько я помню там все гораздо проще, через GUI менеджмент студии решается, а лезть с выборками в системные таблицы не есть правильно.
Авторизацию по сертификатам через ГУИ не настраивается. Когда много баз, проще написать скрипт и запускать его, чем кликать по ГУЮ. Вообще тоже дело вкуса, кто как привык!
Спасибо за статью, как раз была необходимость настройки через сертификаты.
В понедельник испробую все на работе.
Вопросик: такое зеркалирование можно настроить на двух SQL Express-ах?
Нет. Express может выступать только в роли следящего (witness).
UFO just landed and posted this here
Sign up to leave a comment.

Articles