Как сделать дублирующий сервер

Разворачиваем дополнительный контроллер домена на базе Windows Server 2012 R2. Репликация, настройка работы DHCP с основным контроллером домена.

В этой статьe мы разобрали как развернуть контроллер домена на базе Windows Server 2012 R2. Теперь наша задача развернуть дополнительный контроллер домена, который будет подстраховкой в случае если основной выйдет из строя.

Итак мы имеем в работе:

Проделываться все действия будут на виртуальной машине.

Установка Windows Server 2012 R2 и подготовительная настройка системы

Устанавливаем Windows Server 2012 R2 Standart with GUI. После установки системы обязательно:

На этом подготовка системы завершена, можно приступать к развертыванию необходимых ролей.

Поднимаем роли AD DS + DNS + DHCP на дополнительном контроллере домена

Все действия по развертыванию и настройке ролей на дополнительном контроллере домена, мы будем производить с основного контроллера домена. Поэтому заходим в моем случае на основной контроллер домена DC1 (192.168.0.2) и добавим наш дополнительный сервер в основной, Manage — Add Servers.

Переходим во вкладку DNS, в поле Search вбиваем IP-адрес нашего дополнительного сервера (в моем случае 192.168.0.3), сервер должен появится в списке найденных, выделяем его и нажимаем кнопку переместить (>). Нажимаем ОК.

После добавления сервера, если перейти в All Servers, то мы увидим что у нас там теперь два сервера. Теперь можно из основного сервера добавлять, настраивать роли на другом сервере.

Добавляем новую роль на дополнительном сервере DC2. Переходим Server Manager — Manage — Add Roles and Features.

Выбираем первый пункт Role-based or feature-based installation (Базовая установка ролей и компонентов).Нажимаем Next.

Выбираем Select a server from the server pool и выбираем сервер из списка, т.к. мы настраиваем дополнительный сервер, то выделяем dc2.jakonda.local и нажимаем Next.

Далее все как и в статье по развертыванию контроллера домена:

По завершении установки роли AD DS в Server Manager нажимаем на значок Флажка с восклицательным знаком и выбираем Promote this server to a domain controller (Повысить этот сервер до контроллера домена). Запустится мастер конфигурирования AD DS для сервера DC2.

Т.к. мы разворачиваем дополнительный контроллер домена, то нужно добавить его в уже существующий домен. Выбираем Add a domain controller to an existing domain. Автоматические подставится название текущего домена (jakonda.local) и какую доменную учетную запись использовать при выполнении данной операции. Нажимаем Next.

Проверяем установлены ли галочки (Domain Name System (DNS) Server, Global Catalog (GC)), в пункте Site name оставляем значение Default-First-Site-Name и задаем пароль для восстановления служб каталогов. Нажимаем Next.

Предупреждение о том что не может быть создано делегирование разворачиваемого DNS сервера, игнорируем. Нажимаем Next.

В дополнительных опциях в пункте Replicate from (Репликация из) выбираем основной контроллер домена DC1.jakonda.local. Это мы указываем дополнительному контроллеру домена откуда производить репликацию даннных AD, DNS. Нажимаем Next.

Пути к каталогам оставляем по-умолчанию, далее просматриваем сводную информацию по конфигурации AD DS. Нажимаем Next.

Если проверка выполнена успешно, то нажимаем Install.

После того пройдет установка, если зайти на DC2, то увидим что роли AD, DNS подняты, произведена репликация из DC1.

Если необходимо посмотреть, изменить параметры репликации, то заходим Server Manager — Tools — Active Directory Sites and Services.

Так же можно с помощью командной строки принудительно запустить процесс репликации, с помощью утилиты repadmin:

Так же с помощью данной утилиты можно посмотреть результат последних репликаций:

Теперь перейдем к развертыванию DHCP на дополнительном сервере DC2 и его настройке в совместном режиме работы с DHCP на основном сервере DC1.

Поднимаем на дополнительном сервере службу DHCP и настраиваем ее режим работы

Устанавливаем роль DHCP Server аналогично как описано в этой статье только в качестве установки роли выбираем дополнительный сервер.

После установки Роли, в Server Manager нажимаем на значок Флажка с восклицательным знаком и выбираем Complete DHCP configuration (Завершить конфигурацию DHCP). Запустится мастер после установочной конфигурации DHCP. В мастере выполняем следующие действия:

На основном контроллере домена DC1, настроен DHCP-сервер, нужно решить как будет работать DHCP-сервер на дополнительном контроллере домена DC2. Пути решения могут быть такие:

Настройка Split Scope (использование разделенных областей). Открываем оснастку DHCP на основном сервере DC1: Server Manager — Tools — DHCP. Нажимаем правой кнопкой мыши по имени области и выбираем Advanced… — Split Scope.

Описание режима Split-Scope. Нажимаем Next.

Указание дополнительного DHCP сервера, в моем случае DC2. Нажимаем Add Server.

Отмечаем пункт This authorized DHCP server и выбираем дополнительный сервер (dc2.jakonda.local). Нажимаем ОК и следом Next.

Задаем процентное соотношение распределения адресного пула между двумя серверами DC1 и DC2. Ниже видно с какого по какой адрес будет выдаваться основным и дополнительным сервером. Нажимаем Next.

Указываем задержку ответа серверов в мс. Укажем для дополнительного сервера DC2 задержку в 10 мс, выдавать все адреса будет основной сервер DC1, а дополнительный только при недоступности основного или заполнении его пула адресов.

Вывод сводной информации по настройке. Нажимаем Finish.

Если все заданные нами параметры успешно установлены, то напротив каждого пункта будет Successful. Нажимаем Close.

Открываем оснастку DHCP на дополнительном сервере DC2: Server Manager — Tools — DHCP. Нажимаем правой кнопкой мыши по имени области и выбираем Activate.

Теперь при отказе или заполнении выделенного на основной сервер DC1 пула адресов, его подстрахует дополнительный сервер DC2.

Настройка Failover (Отказоустойчивый). Открываем оснастку DHCP на основном сервере DC1: Server Manager — Tools — DHCP. Нажимаем правой кнопкой мыши по имени области и выбираем Configure Failover…

Выбираем пул к которому хотим применить Failover. Нажимаем Next.

В поле Partner Server выберем второй сервер (dc2.jakonda.local). Пункт Reuse existing failover relationships configured with this server (if any exist) (Использовать существующие отношения отработки отказа с этим сервером (если доступно)) будет активно, если ранее уже создавалось отказоустойчивый профиль, то мастер предложит воспользоваться существующим профилем. Нажимаем Next.

Задание отказоустойчивых параметров:

Задаем нужные нам параметры. Нажимаем Next.

Вывод сводной информации по указанной конфигурации. Нажимаем Finish.

Если все заданные нами параметры успешно установлены, то напротив каждого пункта будет Successful. Нажимаем Close.

В рамках текущей задачи, мы настроили работу дополнительного контроллера домена DC2, который в случае отказа основного контроллера домена DC1 подстрахует его.

Источник

Собираем и настраиваем свой CDN

Сети доставки контента (CDN) используются на сайтах и в приложениях в основном для ускорения загрузки статических элементов. Происходит это за счет кеширования файлов на CDN-серверах, расположенных в разных географических регионах. Запросив данные через CDN, пользователь получает их с ближайшего сервера.

Принцип работы и функционал у всех сетей доставки контента примерно одинаков. Получив запрос на загрузку файла, CDN сервер единоразово берет его с оригинального сервера и отдает пользователю, вместе с тем кешируя у себя на заданный промежуток времени. На все последующие запросы ответ отдается из кеша. У всех CDN есть опции предварительной загрузки файлов, очистки кеша, настройки срока его хранения, и многое другое.

Бывает, что в силу тех или иных причин требуется организовать собственную сеть доставки контента, и тогда — да будет в помощь нам инструкция по сборке очередного велосипеда.

Источник: Infographic vector created by pikisuperstar — www.freepik.com

Когда нужен собственный CDN

Рассмотрим случаи, когда запуск собственного CDN имеет смысл:

Что нужно для запуска

Чудно, если у вас есть своя автономная система (AS). С ней можно назначить одинаковый IP нескольким серверам и по этой инструкции на уровне сети направлять пользователей к ближайшему. Cтоит сказать, что даже с блоком адресов /24 есть возможность построить сеть доставки контента. Некоторые сервер-провайдеры позволяют сделать анонс для использования во всех доступных у них регионах.

Если же вы не счастливый обладатель блока IP адресов, то для запуска простого CDN вам понадобятся:

Регистрируем домен и заказываем сервера

С регистрацией домена все просто — регистрируем в любой зоне у любого регистратора. Также для CDN можно использовать субдомен, например что-то вроде cdn.имядомена.com. Собственно в нашем примере мы так и поступим.

Что касается заказа серверов — их стоит арендовать в регионах и странах, где находится ваша пользовательская аудитория. Если проект интерконтинентальный, то удобно выбирать хостинг-провайдеров, предлагающих сразу сервера по всему миру. Примеры: OVH, Leaseweb и 100Tb — для выделенных серверов, Vultr и DigitalOcean — для виртуальных облачных*.

Для нашего частного CDN закажем 3 виртуальных сервера на разных континентах. У Vultr на сервере за $5/мес мы получим 25GB SSD места и 1TB трафика. При установке выберем последний Debian. Наши сервера:

Франкфурт, ip: 199.247.18.199

Чикаго, ip: 149.28.121.123

Сингапур, ip: 157.230.240.216

Настраиваем geoDNS

Чтобы пользователь при обращении к домену или субдомену CDN направлялся на нужный (ближайший к нему) сервер, нам понадобится DNS сервер с функцией geoDNS.

Принцип и порядок работы geoDNS следующий:

Практически у всех DNS-сервисов в стоимость включена незаменимая для построения CDN услуга — DNS Failover. С ее помощью можно настроить мониторинг работы своих серверов и в случае отсутствия признаков жизни автоматически заменять в DNS-ответах адрес нерабочего сервера на резервный.

Для построения нашего CDN воспользуемся ClouDNS, тариф GeoDNS.

Добавим в личном кабинете новую DNS-зону, указав свой домен. Если CDN будем строить на субдомене, а главный домен уже используется, то сразу после добавления зоны не забудьте добавить существующие рабочие DNS-записи. Следующее действие — создание для CDN домена/субдомена нескольких A-записей, каждая из которых будет применяться для заданного нами региона. В качестве регионов можно указать континенты или страны, для США и Канады доступны субрегионы.

В нашем случае CDN будет поднят на субдомене cdn.sayt.in. Добавив зону sayt.in, создадим для субдомена первую A-запись и направим всю Северную Америку на сервер в Чикаго:

Повторим действие для других регионов, не забыв создать одну запись для регионов по умолчанию. Вот что получится в итоге:

Последняя дефолтная запись на скриншоте означает, что все незаданные регионы (а это Европа, Африка, пользователи спутникового интернета и т.д.) будут направляться на сервер во Франкфурте.

На этом базовая настройка DNS завершена. Осталось зайти на сайт регистратора домена и заменить текущие NS-ы домена на те, что выдал ClouDNS. И пока NS-ы будут обновляться мы подготовим сервера.

Установка SSL сертификатов

Наш CDN будет работать по HTTPS, поэтому если у вас уже имеются SSL сертификаты для домена или субдомена, — загрузите их на все сервера, например в директорию /etc/ssl/вашдомен/

Если сертификатов нет, можно получить бесплатный от Let’s Encrypt. Для этого отлично подойдет ACME Shell script. Клиент удобен и прост в настройке, а главное — позволяет проводить валидацию домена/субдомена по DNS через API от ClouDNS.

Мы поставим acme.sh только на одном из серверов — европейском 199.247.18.199, с него сертификаты будут копироваться на все остальные. Для установки выполним:

В ходе установки скрипта будет создано CRON задание для дальнейшего обновления сертификатов без нашего участия.

Проверка домена при выдаче сертификата будет проводиться по DNS с использованием API, поэтому в личном кабинете ClouDNS в меню Reseller API нужно создать нового API пользователя и задать для него пароль. Полученный auth-id с паролем пропишем в файле

/.acme.sh/dnsapi/dns_cloudns.sh (не путать с файлом dns_clouddns.sh). Вот строки, которые требуется раскомментировать и отредактировать:

Теперь запросим получение SSL сертификата для cdn.sayt.in

В параметрах, на будущее, мы указали команду для автоматической перезагрузки конфигурации веб-сервера после каждого обновления срока действия сертификата в дальнейшем.

Весь процесс получения сертификата может занять до 2 минут, не прерывайте его. Если возникнет ошибка валидации домена, попробуйте запустить команду еще раз. В конце мы увидим, куда были загружены сертификаты:

Запомним эти пути, их нужно будет указать при копировании сертификата на другие сервера, а также в настройках веб-сервера. На ошибку перезагрузки конфигов Nginx не обращаем внимания, — на полностью настроенном сервере при обновлении сертификатов ее не будет.

Все что нам осталось по SSL, — это скопировать полученный сертификат на два других сервера с сохранением пути к файлам. Создадим на каждом из них такие же директории и сделаем копию:

Чтобы обновление сертификатов было регулярным создадим на обоих серверах ежедневное CRON задание с командой:

При этом доступ к удаленному серверу-источнику должен быть настроен по ключу, т.е. без ввода пароля. Не забудьте сделать это.

Установка и настройка Nginx

Для отдачи статического контента мы будем использовать Nginx, сконфигурированный в режиме кеширующего proxy-сервера. Обновим списки пакетов и установим его на всех трех серверах:

Вместо дефолтного используем конфиг из спойлера ниже:

В конфиге отредактируем:

Проверяем работу CDN

Результаты хорошие. Разместим теперь в корне основного сайта тестовую картинку test.jpg и проверим скорость ее загрузки через CDN. Сказано, — сделано. Контент отдается быстро.

Напишем небольшой скрипт на случай, если захотим на CDN-точке очистить кеш.

Для удаления всего кеша достаточно просто запустить его, отдельный файл можно почистить так:

Вместо выводов

Напоследок хочу дать несколько полезных советов, дабы сразу переступить через грабли, сделавшие в свое время больную голову мне:

Источник