Давно подумывал о внедрении выделенного сетевого балансировщика, который бы мог, с одной стороны, работать в режиме высокой доступности (кластеризация узлов балансировщика), а с другой стороны, мог бы повысить уровень контроля доступности балансируемых веб-ресурсов. Всевозможные программно-аппаратные решения, как вариант, не рассматривались из-за их высокой стоимости, особенно в контексте реализаций высокой доступности. В эпоху повсеместного применения виртуализации, в качестве более доступного и масштабируемого решения, само собой напрашивается программное решение в виде сконфигурированной виртуальной машины под ту или иную платформу виртуализации. Начал изучать соответствующие варианты. Одними из основных критериев выбора были такие очевидные вещи, как отсутствие финансовых затрат, простота управления (желательно через веб-интерфейс), поддержка высокой доступности. Читать далее...
-
Высоко-доступный балансировщик Zen Load Balancer (ZenLB) Community Edition на базе 64-битной ОС Ubuntu Server 14.04
-
System Center 2012 R2 App Controller Hight Availability на базе узлов кластера Virtual Machine Manager
Несмотря на то, что такой продукт, как App Controller из состава System Center 2012 R2, можно сказать, уже близок к завершению своего жизненного цикла, выполнять его установку и настройку, да ещё и в варианте Hight Availability, мне до сих пор не доводилось. Практика показала, что процедура такого развёртывания имеет свои нюансы, и поэтому в данной заметке я попытаюсь пошагово описать данный процесс. Основным и главным условием развёртывания высоко-доступного App Controller в моём случае будет использование уже имеющихся серверов System Center 2012 R2 Virtual Machine Manager (VMM), то есть установка служб App Controller будет выполняться на узлы действующего кластера VMM, конфигурация которого рассматривалась ранее в заметке Обновляем System Center 2012 SP1 Virtual Machine Manager до уровня System Center 2012 R2 на Windows Server 2012 R2 и SQL Server 2012 SP1 с параллельным переходом в режим Highly Available. -
Повышаем доступность веб-сервера Apache с помощью UCARP с балансировкой нагрузки между двумя виртуальными серверами на базе Ubuntu Server 14.04.2
C помощью описанной в предыдущей заметке конфигурации UCARP можно повысить доступность не только Squid, но и других приложений, например того же веб-сервера Apache, который отвечает у нас за раздачу пользователям файла авто-конфигурации прокси wpad.dat, как это было описано ранее. -
Повышаем доступность прокси-сервера Squid с помощью UCARP с балансировкой нагрузки между двумя виртуальными серверами на базе Ubuntu Server 14.04.2
Несмотря на довольно стабильную работу прокси-сервера Squid в средах с большим количеством пользователей, может возникнуть желание повышения уровня доступности такого важного на сегодняшний день информационного ресурса, как доступ в Интернет для конечных пользователей. В этой заметке будет рассмотрен пример настройки двух прокси-серверов Squid для повышения доступности с параллельным распределением нагрузки между этими серверами. -
Windows Server 2012 R2 Remote Access - Настраиваем VPN сервер с двухфакторной аутентификацией на базе L2TP/IPsec и авторизацией через RADIUS
В этой заметке будет рассмотрен пример настройки VPN-сервиса на базе Windows Server 2012 R2 с ролью Remote Access. Для повышения доступности VPN-сервиса в рассматриваемой далее конфигурации будет использоваться два виртуальных сервера (на базе Hyper-V) объединённых в NLB-кластер. Для повышения гибкости правил предоставления доступа к разным ресурсам локальной сети для VPN-клиентов на стороне VPN-серверов будет выполнена привязка схемы аутентификации к расположенным в локальной сети RADIUS серверам (на базе Network Policy Server). Для повышения безопасности VPN-соединений в качестве основного протокола будет использоваться L2TP/Ipsec с использованием цифровых сертификатов. Двухфакторная аутентификация будет основана на проверке сертификата и доменной учетной записи пользователя Читать далее... -
SQL Server 2012 AlwaysOn и резервные копии. Часть 3 - Восстановление. Перевод статьи
Данный материал является переводом оригинальной статьи "MSDN Blog SQLGardner : SQL 2012 AlwaysOn and Backups - Part 3 - Restore.Иногда вещи должны немного выскальзывать из рук. Во всяком случае давайте немного поговорим о том, как все эти замечательные параметры резервного копирования в SQL Server 2012 могут повлиять на процесс восстановления.
-
SQL Server 2012 AlwaysOn и резервные копии. Часть 2 - Настройка резервного копирования и автоматизация резервного копирования. Перевод статьи
Данный материал является переводом оригинальной статьи "MSDN Blog SQLGardner : SQL 2012 AlwaysOn and Backups - Part 2 - Configuring Backup Preferences and Automating Backups.В предыдущем посте я показал, что можно выполнить резервное копирование из ваших реплик. Мысль, которую вы, возможно, подумали — "Хорошо, это здорово. Но как я узнаю, что это экземпляр реплики, и он не стал основным? Что делать, если для выполнения резервного копирования я хочу использовать конкретный экземпляр реплики, но позволить другому экземпляру иметь возможность сделать это в случае, если тот не доступен?" К счастью команда по продукту продумала такие вопросы и создала некоторые параметры конфигурации для настройки резервного копирования.
-
SQL Server 2012 AlwaysOn и резервные копии. Часть 1 - Разгрузка работы на реплику. Перевод статьи
Данный материал является переводом оригинальной статьи "MSDN Blog SQLGardner : SQL 2012 AlwaysOn and Backups - Part 1 - Offloading the work to a replica".Одним из величайших аспектов SQL Server AlwaysOn является возможность разгрузить работу резервного копирования и проверку целостности в реплику. Это действительно может помочь сохранить ресурсы на вашей основной рабочей нагрузке приложения. Я собираюсь сосредоточиться главным образом на резервных копиях журнала транзакций в этой статье, так как резервное копирование журнала лучше всего использовать для того, чтобы проиллюстрировать эту новую функцию. Одним из ключевых элементов включения этой резервной способности является цепочка одного журнала, которая поддерживается по всем репликам. Проиллюстрирую это, показывая log_reuse_wait_desc sys.databases и выходные данные инструкции DBCC SQLPERF('logspace').
-
System Center 2012 R2 Virtual Machine Manager - Перенос базы данных Highly Available VMM на другой сервер БД без переустановки VMM
При переносе базы данных System Center 2012 Virtual Machine Manager (VMM) с одного SQL сервера на другой способом описанным в заметке SCVMM 2012 — Перенос БД без переустановки VMM в своё время особых проблем не возникало. В ту пору VMM работал как отдельный сервер. При переходе на System Center 2012 R2 конфигурацию VMM было решено расширить и задействовать функционал высокой доступности в кластере их двух серверов VMM, использующих общую базу данных расположенную на отдельном кластере SQL Server. Однако наступил момент, когда кластеризованную БД VMM потребовалось перенести из одного кластера SQL Server в другой, и тут описанный ранее метод не сработал. Дело в том, что в кластерной конфигурации предлагаемые к изменению параметры реестра входят в ключ реестра HKLM\SOFTWARE\Microsoft\Microsoft System Center Virtual Machine Manager Server\Settings, который является реплицируемым между узлами кластера. Это можно увидеть например в оснастке Failover Cluster Manager если открыть свойства кластерной службы VMM Service на закладке Registry Replication
Таким образом, чтобы успешно изменить параметры реестра в этом ключе, нам потребуется выполнить некоторую последовательность действий.
-
Миграция сервера DHCP c Windows Server 2008 R2 на отказоустойчивую конфигурацию DHCP Failover из двух серверов на базе Windows Server 2012 R2
В процессе миграции серверных систем на Windows Server 2012 R2 дошли до служб DHCP и решили попробовать в действии новый механизм повышения доступности DHCP Failover появившийся еще в Windows Server 2012. Перед началом процедуры возьмём на заметку пару тезисов из документации по DHCP Failover: Для отработки отказа DHCP можно использовать не более двух DHCP-серверов Для правильной работы отработки отказа DHCP необходимо синхронизировать время на двух серверах в отношениях отработки отказа. Для синхронизации времени можно использовать протокол NTP или любой альтернативный механизм. Мастер настройки отработки отказа сравнивает текущее время на серверах, настроенных для отработки отказа. Если время на серверах отличается более чем на одну минуту, установка отработки отказа завершится с критической ошибкой, указывающей администратору на необходимость синхронизации времени на серверах.
Последовательность выполняемых действий:
1. Устанавливаем роль DHCP Server на два сервера с Windows Server 2012 R2.
2. Экспортируем данные действующего сервера DHCP с Windows Server 2008 R2
3. Импортируем все конфигурационные данные DHCP на первый сервер с Windows Server 2012 R2
4. Импортируем только серверную конфигурацию DHCP на второй сервер с Windows Server 2012 R2
5. Настраиваем DHCP Failover.
6. Заключительные процедуры
Онлайн-курсы Евгения Лейтана
Внедрение Microsoft System Center Operations (SCOM) 2016/201913 уроков (6 часов видео), лабораторные работы и вручение именного сертификата.
Промокод "IT-KB_60" со скидкой 60%!
RSS - Записи