Автоматическое переключение на зеркальную БД при сбое сервера. #450479

Доброго времени суток. Возникла такая ситуация: Есть два физических сервера. На обоих серверах установлены сервера приложений 1с 8.1 и СУБД MS SQL Server 2005 Standard Edition, ОС: Windows Server 2008 Standard Edition. Средствами SQL Server организовано зеркальное отображение базы данных с рабочего сервера на резервный. В данный момент, в случае выхода из строя рабочего сервера, witness-сервер делает доступной базу на резервном. На этом удобства заканчиваются - приходится руками менять каждому пользователю (60-70 человек) путь к ИБ (точнее изменять имя кластера серверов 1С). Вопрос - можно ли каким-нибудь образом делать это автоматически? Прописывать дополнительную базу - как-то не эстетично, что ли.. На скрипт вешать не хочется, кажется не очень надежным.. Сейчас играемся с 8.2 и ее отказоустойчивым кластером, но отказоустойчивость, увы, распространяется исключительно на сервер приложений 1С, но никак не на SQL Server. Построить кластер на базе SQL Server'a не получится - Windows Server 2008 Standard Edition такой возможности не дает, а покупать Enterprise - накладно.

В "приходится менять" - это я погорячился, пока (тьфу-тьфу-тьфу) не приходилось, но ежели чего не так - придется.

Можно сделать ярлык на базу и на общий сетевой ресурс, пусть по нему запускают.

Храни список баз на сервере, а юзерам указывай путь к списку общих баз. Тогда в одном месте достаточно будет менять. И удобно, опять же. З.Ы. У вас, я так понимаю, в синхронном режиме? А как быстродействие? И сколько доков в день добавляется в среднем?

, Этои варианты тоже рассматривали, но не хочется зависеть еще от одного сервера. Если на нем надо будет провести какие-нибудь регламентные работы - зайти в 1С никто не сможет. Да, синхронный. Быстродействие заметно не упало. Доков порядка 3-5 тысяч, они относительно небольшие - 7-10 строк в табличных частях. Сервера между собой соединены по гигабитному каналу.

чтобы не зависеть от одного сервера юзайте dfs и публикацию папки в домене. Если у папки, в которой лежат списки баз, будет несколько зеркал, то хрен с ним, пусть зеркала по очереди падают - не страшно. Конечно до тех пор, пока АД не упадет.

интересно, а ведь действително, имхо, нет обработчика события типа "ПриПотереСвязиССУБД", чтобы это коть как то попытаться разрулить и не вывалиться в аут. или есть?

виртуализация спасет отца русской демократии

А ещё нет обработчика ПриПитаниеКомпьютераВыключено...

А в , на сколько я понимаю, речь и не идет о том, чтобы пользователи совсем не заметили падения сервера БД. Речь идет о том, чтобы работа насовсем не остановилась

" Доков порядка 3-5 тысяч" - в день? О_о

я мечтаю... :) это за пределами моих мечт :)

, я мечтаю :) об этом я даже и мечтать не могу :)

Да. Я SQL Server на виртуальный сервер не дам поставить, спасибо. Мне религия не позволяет. Спасибо, почитаем. В вы абсолютно правы.

.2 почему?

переходи на 8.2 с поддержкой 8.1. Там зеркальность на уровне движка 1С реализована

ходи на сервер 1С по айпишнику

+ мой админ говорит что СКЛ можно настроить так что при падении основного зеркало само на себя возьмет роль основного и никто даже ничего не заметить, максимум мошт транзакция не зафиксироваться

Для файловых помоек и прочего - без проблем. От sql'я в первую очередь требуется производительность, деградация которой обязательно возникнет. Где можно подробнее про это почитать? В "Руководстве администратора" об этом ни слова. Отказоустойчивый кластер не спасает. Чтобы при вылете сервера руками ip менять? А потом когда старый оживет, чтобы конфликты возникли?

п3   угу, проще один ip перебить, ну и помнить про это а сбойный сервер в сеть уже не пускать

.1 деградация не более 5-10%. ну и перенос на более новое железо в разы приятнее

+ причем без остановки основной работы

2. нам на курсах говорили с картинками. Там надо добавить новый кластер и установить ему признак "Зеркало"

Гм... Мы тут просто размышляем над тем, чтобы такую же штуку провернуть :) А насчет списков баз - оченно удобная штука. Теперь разруливаем списки через AD и в ус не дуем :)

не самое "красивое" решение + время простоя до приезда человека способного поменять IP (сейчас это минимум 25 минут). Этого хочется избежать. , Перенос удобен, согласен. По поводу производительности - это все в теории. Возможно, когда железо будет позволять, будем об этом думать. Сейчас - совершенно не вариант. Облазил всю консоль сервера. Так и не нашел где установить признак "Зеркало". А жаль..

3.

А поподробней насчет списка баз через AD? Или где почитать об этом можно?

Увы, не то. Это параметры рабочего процесса, а не кластера серверов. Если один РП загибается, его место займет резервный. Для моей задачи, к сожалению, бесполезно

Делаешь файл "ibases.v8l", где тупо перечисляешь путь к файлам "ibases.v8i" - спискам баз. Если его в "C:Documents and Settings<Юзер>Application Data1C1Cv81", то 1С при запуске будет подключать файлы со списками баз из него. Если теперь не давать пользователям доступа к самим спискам (*.v8i), то этих баз они видеть не будут. Ну и меняя 1 файл, меняешь его для всех юзверей.

3-5 тысяч доков в день и нет денег на Enterprise? Я понимаю, что начальство стремится каждую копейку денег, которые не на них лично идут, сэкономить, но не до такой же степени ...

Спасибо, только я, честно говоря, думал, что будет нечто вроде оснастки *.msc для этих целей...

на лине раализуеться на раз два а вот под виндой та еще проблема....

Метод неинтересный, Заводишь DNS сервак, прописываешь путь к базе через имя, при крушении 1-го сервера, пользователе вылетают (IP имени меняется) и пользователи сного заходят в 1С... А вообще порекомендовал бы 3-ю машинку чисто под 1С, а 2 SQL-сервачка... Меньше геморою при смене IP базы...

вместо стандартного ярлыка запуска 1с, ярлык на v8i-файл \NetPath1C.v8i Делаешь 2 v8i файла с настройками для соответствующих СП 1С. При сбое переименовываешь нужный и все. Вроде :)

Итак, мы пошли своем путем (:. Есть два сервера tsrv1 и tsrv2. На обоих серверах установлены кластеры серверов 1С 8.2 и SQL Server 2005 Standard Edition. Кластера серверов 1С объединены в группу резервирования, первым идет tsrv1. Крутятся базы test и ztest - зазеркалены (синхронное зеркало с автматическим переходом на другой ресурс). На tsrv1 прописаны следующие базы (автоматом их подхватывает): 1. test (сервер СУБД tsrv1, БД test) 2. ztest (сервер СУБД tsrv1, БД ztest) 3. test2 (сервер СУБД tsrv2, БД test - зеркальная бд, в данный момент в состоянии restore) 4. ztest2 (сервер СУБД tsrv2, БД ztest - так же) На tsrv2, до тех пор пока базы данных являются зеркальными (т.е. недоступны пользователю) крутится такой job: [1c] declare @test_role int, @test_state int; declare @ztest_role int, @ztest_state int; declare @test_id smallint, @ztest_id smallint; select @test_id = database_id from sys.databases where name = 'test'; select @ztest_id = database_id from sys.databases where name = 'ztest' select    @test_role = role,        @test_state = status from msdb.dbo.dbm_monitor_data where database_id = @test_id select    @ztest_role = role,        @ztest_state = status from msdb.dbo.dbm_monitor_data where database_id = @ztest_id if @test_role=0 and @ztest_role=0 --если роли поменялись - меняем файлы и живем счастливо    begin        exec xp_cmdshell 'rename C:ackases.v8i bases.v8bak', no_output        exec xp_cmdshell 'rename C:ackases_temp.v8i bases.v8i', no_output        exec xp_cmdshell 'rename C:ackases.v8bak bases_temp.v8i', no_output                EXEC msdb.dbo.sp_detach_schedule                            @job_name = 'Check mirror',                            @schedule_name = 'check_mirror' ;    end [/1c] Пользователи берут список ИБ из списка общих ИБ, который у всех лежит в папке "C:Program Files1cv82". При включении компьютера пользователя VBS-скрипт ломится на tsrv2, забирает оттуда файл со списокм общих информационных баз и кладет его в указанную папку. Если tsrv2 недоступен, этот же скрипт пытается получить файл со списком ИБ с tsrv1. Если не может - увы, вероятно, отдыхают оба сервера. [1c] CompName = "tsrv2"    'имя компьютера с которого мы хотим забрать файл net_path = "//tsrv2/back$/bases.v8i" res_path = "//tsrv1/back$/bases.v8i" local_path = "C:Program Files1cv82ases.v8i" Const OverwriteExisting = TRUE Set objFSO = CreateObject("Scripting.FileSystemObject") Set objPing = GetObject("winmgmts:{impersonationLevel=impersonate}")._        ExecQuery("select * from Win32_PingStatus where address = '"_        & CompName & "'") For Each objStatus In objPing   If IsNull(objStatus.StatusCode) or objStatus.StatusCode<>0 Then    'если сервер недоступен, тянем со второго    CompName2 = "tsrv1"    Set objPing2 = GetObject("winmgmts:{impersonationLevel=impersonate}")._            ExecQuery("select * from Win32_PingStatus where address = '"_            & CompName2 & "'")    For Each objStat In objPing2       If IsNull(objStat.StatusCode) or objStat.StatusCode<>0 Then                'если второй сервер так же недоступен - ничего не делаем, надеемся, что глюк       else        objFSO.CopyFile res_path, local_path, OverwriteExisting        'тянем файл со второго сервера end if next    else    objFSO.CopyFile net_path, local_path, OverwriteExisting    'здесь тянем файл     end if next [/1c] Файл, лежащий на tsrv1 содержит в себе пути к базам test и ztest (т.е. обычные пути - когда все работает). На tsrv2 job проверяет состояние зеркального отображения и либо оставляет такой же файл, либо подменяет его файлом с базами test2 и ztest2. Запускается он раз в две минуты, после смены файлов - запускаться перестает, надо будет включать руками. До конца пока не оттестировано, но для одного клиента выключение tsrv1 проходит на ура. Если где-то что-то можно сделать попроще - буду рад мнениям (:.

у меня есть обработка(на страничку блокнотика) которая переключает всех пользователей с одного сервера на другой (сделано на случай внезапной облавы). Тебе случаем не это надо??

Если обработка сама понимает, что первый сервер загнулся и автоматом переводит всех на другой сервер - то, да, именно это (:.

когда сервер загнется  - обработка уже ничего не поймет...она тоже загнется))