K-sh, не удобен по простою? Если имеет ввиду что серваки разные то это не проблема, у акрониса есть прикольная штука Universal Restore. Так вот если копия накатывается на другой по железу сервак то с помощью данной штуки можно все хорошо прикрутить.
Ну а если хотите кластер делать то придется заморочиться насчет внешнего хранилища и подъемом кластера.
K-sh, Пару раз накатывал, без всяких проблем. Да и много тестов делал. Например накатывал с сервака где было два проца на сервак с одним процом. С другой мамкой тоже делал. Потом универсал ресторе и все гуд.
Можете сами провести эксперимент, звять копию с работающего и накатить на резервный. Резервный только из сети надо откл. чтобы небыло конфликтов ип-адресов после полного востановления.
Создание зеркала (программного RAID 1) для Windows
Это создание программного RAID в конфигурации RAID 1 с целью сохранности информации и получения доступа к среде ОС при неполадках, вызванных проблемами с обеспечивающим её существование жёстким диском. Каковы особенности этого механизма, и как его реализовать в среде Windows – об этом всём будем в деталях говорить ниже.
1. Зеркалирование Windows: что это
Зеркалирование — это, как упоминалось, программный RAID 1, часто используемая конфигурация дискового массива, при которой данные дублируются на второй, именуемый зеркалом жёсткий диск. При возникновении неполадок с первым, основным жёстким диском с помощью зеркала сможем получить доступ к нашей ценной информации. Более того, если зеркалирование применятся к системным разделам Windows, при поломке основного диска мы не просто получим доступ к информации, хранящейся в системе, мы даже попадём внутрь неё. Не внутрь неё исходной, но внутрь точного её клона на диске-зеркале.
2. Подготовительный этап
Для применения к Windows программного RAID 1 к компьютеру должен быть подключён второй жёсткий диск с вместимостью не менее суммарного объёма обоих системных разделов. В нашем случае таковые занимают, соответственно, 549 Мб и 60 Гб, а диск-зеркало имеет объём с небольшим запасом – 70 Гб. Зеркало необходимо подготовить к его дальнейшей участи – удалить на нём все разделы. Должна остаться чистая нераспределённая область.
3. Преобразование диска в динамический
На любом из двух дисков вызываем контекстное меню, выбираем преобразование их в динамический тип.
После увидим, как на зеркале образовался раздел-клон и запустился процесс синхронизации данных.
Теперь жмём контекст-меню на основном разделе Windows, на диске С. И проделываем ту же операцию, что и выше. Добавляем зеркало.
5. Зеркальная Windows
Можно установить меньшее время для автовыбора Windows.
Первой будет загружаться система на основном диске, так что можно выбрать минимальные 5 секунд для отображения вариантов загрузки.
В старых версиях Виндовс таймаут для меню загрузчика настраивается в системной утилите «Конфигурация системы».
Далее в меню загрузчика выбираем систему с допиской «вторичный плекс», т.е. Windows на зеркальном диске.
6. Удаление зеркал Windows
Выбираем диск-зеркало, жмём кнопку его удаления и подтверждаем.
Пространство зеркального диска превратится в нераспределённую область, и его тип из динамического преобразуется в исходный базовый.
7. Переустановка Windows в условиях зеркалирования
Переустановка Виндовс в условиях существования зеркал её разделов осуществляется так же, как обычно – можем удалить два её раздела и местом установки ОС указать неразмеченную область, а можем просто отформатировать два существующих её раздела.
Так что раздел загрузки Windows при её переустановке в обязательном порядке нужно либо форматировать, либо удалять. Как же тогда обеспечить вход в зеркальную Windows? Решение здесь очень простое: нужно пересоздать зеркала системных разделов – удалить их, как рассмотрено в предыдущем пункте, и назначить заново. Диск-зеркало заново синхронизуется с системными разделами, а в меню загрузчика Windows опять появится пункт зеркальной системы с допиской «вторичный плекс».
Для настройки зеркалирования на MSSQL для начала необходимо настроить доступ между ними. Один сервер у нас будет основной, а второй зеркальный. Первое что надо сделать, это настроить доступ между этими серверами, разрешить порты (по молчанию 1433-1434) и наши порты, которые мы укажем в настройках. ВАЖНО Наша база данных должна иметь модель восстановления “FULL” И так 1. Создаем сертификат и контрольную точку «DBMirrorEndPoint» на основном сервере, указав в сертификате пароль, дату актуальности и сохраним его в папку (для примера в D:\Certificate), также укажем порт для соединения (для примера 5022)
2. Создаем сертификат и контрольную точку «DBMirrorEndPoint» на зеркале, аналогично основному
У нас есть сертификаты и контрольные точки, для соединения 2 серверов необходимо создать юзеров на обоих, привязав их к нашим сертификатам.
3. Копируем сертификаты с одного сервера на другой, в папке с сертификатами (у нас ‘D:\Certificate\’) должно быть по 2 сертификата.
4. Создаем на основном сервере юзера «MirrorUser», этого юзера привязываем к сертификату из зеркала «MirrorServerCert»
5. Создаем на зеркале юзера «PrincipalUser», этого юзера привязываем к сертификату из основного сервера «PrincipalDBCertPub»
Связь между серверами готова. Теперь надо настроить базы данных.
1. Делаем бэкап рабочей базы. BACKUP DATABASE [Наша база] TO DISK = N’D:\Наша база.bak’ WITH FORMAT, INIT, NAME = N’MIRROR_TEST-Full Database Backup’,STATS = 10 2. Поднимаем бэкап на зеркале
Перенесем файл бэкапа на зеркало (у нас, в корень диска D), укажем путь к файлам БД
RESTORE DATABASE [Наша база] FROM DISK = ‘D:\ Наша база.bak’ WITH NORECOVERY ,MOVE N’MIRROR_TEST’ TO N’D:\MSSQL_DB\Наша база.mdf’ ,MOVE N’MIRROR_TEST_log’ TO N’D:\MSSQL_DB\Наша база_log.ldf’ 3. Запускаем зеркалирование на зеркале
ALTER DATABASE MIRROR_TEST SET PARTNER = ‘TCP://основной сервер:5022’
4. Потом на основном
ALTER DATABASE MIRROR_TEST SET PARTNER = ‘TCP://зеркало:5023’ 5. Для того чтобы подключатся с 1С к любой из баз необходимо применить асинхронный режим зеркалирования
— Task — Mirror — Hight performance (asynchronous) (— Задачи — Создать зеркальное отображение — Высокая производительность (асинхронный))
Теперь можно работать на двух базах одновременно. Данные будут передаватся между ними
Изменить роли сервера можно в — Task — Mirror — Failover (— Задачи — Создать зеркальное отображение — Отработка отказа)
Если основная БД упала, то нужно оживить зеркало запустив ALTER DATABASE MIRROR_TEST SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS После этой команды зеркальная база становится основной, а основная после решения проблем станет зеркальной и будет синхронизироваться з основной
K-sh, не удобен по простою? Если имеет ввиду что серваки разные то это не проблема, у акрониса есть прикольная штука Universal Restore. Так вот если копия накатывается на другой по железу сервак то с помощью данной штуки можно все хорошо прикрутить.
Ну а если хотите кластер делать то придется заморочиться насчет внешнего хранилища и подъемом кластера.
K-sh, Пару раз накатывал, без всяких проблем. Да и много тестов делал. Например накатывал с сервака где было два проца на сервак с одним процом. С другой мамкой тоже делал. Потом универсал ресторе и все гуд.
Можете сами провести эксперимент, звять копию с работающего и накатить на резервный. Резервный только из сети надо откл. чтобы небыло конфликтов ип-адресов после полного востановления.
Как сделать зеркалирование хостинга на двух серверах?
Вопрос в следующем: существуют два хостинговых сервера. В разных сетях. Необходимо сделать полное зеркалирование всех виртуальных хостов на них (неважно какими методами), и это не самое сложное. Самое сложное в том КАК сделать так чтобы автоматически хостинг мог бы переключаться с одного сервера на другой, в зависимости от того работает ли первый сервер или второй. Одним словом, мне необходимо наладить, можно так сказать, «резервный хостиг».
Вопрос заключает в пунктах:
При такой архитектуре узким местом будет являеться DNS сервер.
Давайте пока отрешимся от конкретной реализации. В любом случае есть централизованная система, «разруливающая» запросы между основным и запасным серверами. Понятное дело, что она располагается на железке и подключена к Сети, т.е. ее надежность (в рамках данной задачи) равна надежности каждого из хостинг-серверов в отдельности. Надежность системы определяется надежностью самой ненадежной компоненты. Таким образом получаем, что надежность всей системы тождественно равна надежности первоначальной системы. Следовательно, городить весть этот огород я не вижу никакого смысла.
Секондарей может быть несколько, а надежности 100% не бывает по определению 🙁 Когда строить такую систему (т.е. не хватает надежности, даваемой большими колокаторами), то это скорей всего будут оба моих сервера, а с ними я наиздеваюсь как захочу.
Дмитрий Кольцов (tentura): Картинка впечатляющая. Это были именно географически распределенные сервера?
Чем больше компонентов в системе, тем больше вероятность выхода одного из них из строя, и соответственно переход системы в целом в нестабильное состояние. Т.е. необходимо предусмотреть и просчитать как можно больше вариантов неисправностей отельных компонентов системы, ликвидации неисправностей на уровне компонентов и ликвидации неисправностей уже на уровне системы в целом. Хотя бы просчитать, об автоматическом восставнолении я пока вообще молчу 🙂
А вот и нет, твой подход решает только 33% описаных проблем и не решает:
Давайте не будем гадать, а спросим уважаемого Андрея Мирона, каковы приоритеты перечисленных им пунктов. Если все-таки пункт б), то тогда это описанное мной в теории и продемонстрированное Дмитрием на практике решение с центральной разруливающей системой.
2 Андрей Новиков: хорошо подмечено 🙂
Мне лично решение очень понравилось, и я думаю цель моего вопроса в этом форуме достигнута.
Программный продукт: Система мониторинга и балансировки нагрузки веб-северов на базе технологии HOF.DNS
Технические характеристики и системные требования: Скорость перераспределени траффика(по результам тестов): — 90% траффика перераспределяется за 20 секунд — еще 8-9% в течении 5 минут — остальные 1-3% в течении 30 минут Резервирование: для каждого hostname возможно определение одного основного и до 3 резервных серверов[IP ]. OS: FreeBSD или Linux. возможна адаптация к другим Unix-подобным database: требуется выделенная БД в СУБД MySQL Управление: веб-интерфейс или коммандная строка MySQL Формат записей DNS: система заменяет DNS сервер, форомат DNS зон аналогичен BIND 8
Сопровождение и установка: Установка и консультации в течении 1 года включены в стоимость.
Сроки: Установка в течении 1 дня после получения оплаты.
Контракт и оплата: Заключение контракта по факсу с последующим подтверждением по почте. Поставщик: Host on Fly SA, Salita Viarno 2, CH-6962, Viganello, Switzerland Оплата: wire transfer, webmoney, paypal
Это мое мнение, только лишь мнение. Решений мы еще никаких не принимали.
