Доброго дня, уважаемый читатель!
Полагаю, если ты пришел на эту страницу, значит у тебя тоже нет опыта в администрировании серверов MSSQL как и у меня, а так же у тебя есть интересный challenge, который ты принял на себя! Молодец!
На написание данной статьи меня подвигло то, что описанное мною ниже решение или что-то подобное я ни разу не встретил на просторах великого и могучегорусского языка..
Однажды передо мною встала задача - настроить бесперебойную работу баз данных для 1с.
В моем распоряжении оказалось два неплохих по характеристикам стоечных сервера. Один уже был в режиме production, вот и его нужно было обеспечить горячей заменой. Суть проблемы в том, что хоть сервер и неплохой, но он довольно старый и зародилось опасение в душах сотрудников, в основном у руководства, что когда-нибудь он покинет этот бренный мир, что вполне обосновано. Какое бы ни было хорошее железо, оно стареет и приходит в непригодность. Второй сервер был так же старым, но он почти не использовался.
Т.к. я никогда не админил сервера MSSQL, даже не устанавливал, мне они просто достались в наследство от предыдущего админа, который, к слову, был, своего рода, гуру и это естественно, что он поменял работу на более оплачиваемую и оставил всё мне, благо, он всё сделал хорошо и поэтому ничего не ломалось само собой, мною было перелопачены мегабайты web-страниц со всевозможных форумов, ютубов и официальной документации, собраны в единое какое-никакое знание об этой каше и выложено сюда.
Итак начнем.
У MSSQL есть несколько способов держать свои базы на плаву (обо всех способах, дорогой читатель, написано в интернете, и как только ты их изучишь, у тебя не будет вопросов, почему я выбрал именно такой метод), и т.к. у меня было в распоряжении только два сервера и сервер ESXi, было принято реализовать следующую схему:
Два сервера MSSQL, назовем их DB1 и DB2 мы настроим для работы в режиме зеркалирования со свидетелем (тут хорошо видно как это делается в 2 щелчка), для которого мы создадим виртуальную машину с установленным на нем MS SQL Express Edition - он-то и позволит нам менять роли между DB1 и DB2 (роли всего 2: это Principal - основной сервер MSSQL и Mirror - очевидно, зеркальное отображение c DB1 на DB2).
Есть сервер 1с, для которого необходимо организовать автоматическое переключение между DB1 и DB2. Всё, что нам нужно для этого это работающий механизм переключения, без вмешательства со стороны пользователей и программистов 1с. Из всего имеющегося у меня арсенала, я выбрал такую реализацию:
В нашу кашу добавился Linux-сервер на Debian, с настроенным iptables для автопереключения.
Сам процесс автопереключения происходит следующим образом:
1) Сбой в работе DB1 вызывает событие в системном журнале сервера-свидетеля (Witness), к которому прикреплена задача на посылку сигнала на Linux-сервер. Передача сигнала осуществляется запуском программы (набыдлокоженной мною на C#), которая открывает URL вида http:///mssql-alert.php, PHP-скрипт рождает пустой файл /tmp/witness-signal.
2) На Linux-сервере каждые 5 секунд срабатывает скрипт который ищет файл-сигнал и меняет всего лишь одно правило в iptables, чтобы не рвать остальные устоявшиеся соединения. Хочу сказать новичкам, что необязательно иметь кучу сетевых карт на Linux, и необязательно держать сервера в разных подсетях, у меня всё работает в одной подсети.
3) На сервере 1с в это время обрываются пользовательские сессии и появляется уведомление со всяким говном и кнопкой "перезапустить" - это единственное вмешательство со стороны пользователя.
Вот и всё!
P.S. Всё это пока реализовано в виде стенда на виртуальных машинах и нерешенным остался вопрос ежедневного сохранения резервных копий БД, т.к. стандартными средствами MSSQL сделать резервную копию зеркалируемой БД у меня не получилось. Сейчас мои мысли направленны на изучение PowerShell, и задумка заключается в скрипте, который будет проверять состояние БД: если БД зеркальная (не основная), то бэкапить не надо, а если она стала основной, то забэкапить. А также интересен вопрос failback-операции, это когда роль Principal автоматически возвращается на DB1 после его возвращения в строй. Если вы что-то знаете об этом, пожалуйста поделитесь опытом.
Если вам нужны исходники скриптов и программы, то пишите в комментах, вышлю почтой, ибо позориться говнокодом желания нет. Основная цель статьи - рассмотреть еще один вариант автопереключения 1с, который я не нашел в интернетах, и скорее всего потому, что это самый очевидный вариант в таких условиях.
Полагаю, если ты пришел на эту страницу, значит у тебя тоже нет опыта в администрировании серверов MSSQL как и у меня, а так же у тебя есть интересный challenge, который ты принял на себя! Молодец!
На написание данной статьи меня подвигло то, что описанное мною ниже решение или что-то подобное я ни разу не встретил на просторах великого и могучего
Однажды передо мною встала задача - настроить бесперебойную работу баз данных для 1с.
В моем распоряжении оказалось два неплохих по характеристикам стоечных сервера. Один уже был в режиме production, вот и его нужно было обеспечить горячей заменой. Суть проблемы в том, что хоть сервер и неплохой, но он довольно старый и зародилось опасение в душах сотрудников, в основном у руководства, что когда-нибудь он покинет этот бренный мир, что вполне обосновано. Какое бы ни было хорошее железо, оно стареет и приходит в непригодность. Второй сервер был так же старым, но он почти не использовался.
Т.к. я никогда не админил сервера MSSQL, даже не устанавливал, мне они просто достались в наследство от предыдущего админа, который, к слову, был, своего рода, гуру и это естественно, что он поменял работу на более оплачиваемую и оставил всё мне, благо, он всё сделал хорошо и поэтому ничего не ломалось само собой, мною было перелопачены мегабайты web-страниц со всевозможных форумов, ютубов и официальной документации, собраны в единое какое-никакое знание об этой каше и выложено сюда.
Итак начнем.
У MSSQL есть несколько способов держать свои базы на плаву (обо всех способах, дорогой читатель, написано в интернете, и как только ты их изучишь, у тебя не будет вопросов, почему я выбрал именно такой метод), и т.к. у меня было в распоряжении только два сервера и сервер ESXi, было принято реализовать следующую схему:
Два сервера MSSQL, назовем их DB1 и DB2 мы настроим для работы в режиме зеркалирования со свидетелем (тут хорошо видно как это делается в 2 щелчка), для которого мы создадим виртуальную машину с установленным на нем MS SQL Express Edition - он-то и позволит нам менять роли между DB1 и DB2 (роли всего 2: это Principal - основной сервер MSSQL и Mirror - очевидно, зеркальное отображение c DB1 на DB2).
Есть сервер 1с, для которого необходимо организовать автоматическое переключение между DB1 и DB2. Всё, что нам нужно для этого это работающий механизм переключения, без вмешательства со стороны пользователей и программистов 1с. Из всего имеющегося у меня арсенала, я выбрал такую реализацию:
В нашу кашу добавился Linux-сервер на Debian, с настроенным iptables для автопереключения.
Сам процесс автопереключения происходит следующим образом:
1) Сбой в работе DB1 вызывает событие в системном журнале сервера-свидетеля (Witness), к которому прикреплена задача на посылку сигнала на Linux-сервер. Передача сигнала осуществляется запуском программы (набыдлокоженной мною на C#), которая открывает URL вида http://
2) На Linux-сервере каждые 5 секунд срабатывает скрипт который ищет файл-сигнал и меняет всего лишь одно правило в iptables, чтобы не рвать остальные устоявшиеся соединения. Хочу сказать новичкам, что необязательно иметь кучу сетевых карт на Linux, и необязательно держать сервера в разных подсетях, у меня всё работает в одной подсети.
3) На сервере 1с в это время обрываются пользовательские сессии и появляется уведомление со всяким говном и кнопкой "перезапустить" - это единственное вмешательство со стороны пользователя.
Вот и всё!
P.S. Всё это пока реализовано в виде стенда на виртуальных машинах и нерешенным остался вопрос ежедневного сохранения резервных копий БД, т.к. стандартными средствами MSSQL сделать резервную копию зеркалируемой БД у меня не получилось. Сейчас мои мысли направленны на изучение PowerShell, и задумка заключается в скрипте, который будет проверять состояние БД: если БД зеркальная (не основная), то бэкапить не надо, а если она стала основной, то забэкапить. А также интересен вопрос failback-операции, это когда роль Principal автоматически возвращается на DB1 после его возвращения в строй. Если вы что-то знаете об этом, пожалуйста поделитесь опытом.
Если вам нужны исходники скриптов и программы, то пишите в комментах, вышлю почтой, ибо позориться говнокодом желания нет. Основная цель статьи - рассмотреть еще один вариант автопереключения 1с, который я не нашел в интернетах, и скорее всего потому, что это самый очевидный вариант в таких условиях.
Комментариев нет:
Отправить комментарий