Собрание заметок об информационных технологиях
26 апреля 2016 (во вторник) с 18-00 до 21-00 состоится очередное 13-ое мероприятие сообщества UC² по адресу г. Москва, ул. Лесная, дом 9, Технологический центр Microsoft (MTC). Тем, кто не сможет присутствовать лично, будет доступна ссылка на онлайн участие после регистрации (см. ниже). Читать далее...
Давно подумывал о внедрении выделенного сетевого балансировщика, который бы мог, с одной стороны, работать в режиме высокой доступности (кластеризация узлов балансировщика), а с другой стороны, мог бы повысить уровень контроля доступности балансируемых веб-ресурсов. Всевозможные программно-аппаратные решения, как вариант, не рассматривались из-за их высокой стоимости, особенно в контексте реализаций высокой доступности. В эпоху повсеместного применения виртуализации, в качестве более доступного и масштабируемого решения, само собой напрашивается программное решение в виде сконфигурированной виртуальной машины под ту или иную платформу виртуализации. Начал изучать соответствующие варианты. Одними из основных критериев выбора были такие очевидные вещи, как отсутствие финансовых затрат, простота управления (желательно через веб-интерфейс), поддержка высокой доступности. Читать далее...
Несмотря на то, что такой продукт, как 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.
C помощью описанной в предыдущей заметке конфигурации UCARP можно повысить доступность не только Squid, но и других приложений, например того же веб-сервера Apache, который отвечает у нас за раздачу пользователям файла авто-конфигурации прокси wpad.dat, как это было описано ранее.
Несмотря на довольно стабильную работу прокси-сервера Squid в средах с большим количеством пользователей, может возникнуть желание повышения уровня доступности такого важного на сегодняшний день информационного ресурса, как доступ в Интернет для конечных пользователей. В этой заметке будет рассмотрен пример настройки двух прокси-серверов Squid для повышения доступности с параллельным распределением нагрузки между этими серверами.
В этой заметке будет рассмотрен пример настройки VPN-сервиса на базе Windows Server 2012 R2 с ролью Remote Access. Для повышения доступности VPN-сервиса в рассматриваемой далее конфигурации будет использоваться два виртуальных сервера (на базе Hyper-V) объединённых в NLB-кластер. Для повышения гибкости правил предоставления доступа к разным ресурсам локальной сети для VPN-клиентов на стороне VPN-серверов будет выполнена привязка схемы аутентификации к расположенным в локальной сети RADIUS серверам (на базе Network Policy Server). Для повышения безопасности VPN-соединений в качестве основного протокола будет использоваться L2TP/Ipsec с использованием цифровых сертификатов. Двухфакторная аутентификация будет основана на проверке сертификата и доменной учетной записи пользователя Читать далее...
Данный материал является переводом оригинальной статьи "MSDN Blog SQLGardner : SQL 2012 AlwaysOn and Backups - Part 3 - Restore.
Иногда вещи должны немного выскальзывать из рук. Во всяком случае давайте немного поговорим о том, как все эти замечательные параметры резервного копирования в SQL Server 2012 могут повлиять на процесс восстановления.
Данный материал является переводом оригинальной статьи "MSDN Blog SQLGardner : SQL 2012 AlwaysOn and Backups - Part 2 - Configuring Backup Preferences and Automating Backups.
В предыдущем посте я показал, что можно выполнить резервное копирование из ваших реплик. Мысль, которую вы, возможно, подумали — "Хорошо, это здорово. Но как я узнаю, что это экземпляр реплики, и он не стал основным? Что делать, если для выполнения резервного копирования я хочу использовать конкретный экземпляр реплики, но позволить другому экземпляру иметь возможность сделать это в случае, если тот не доступен?" К счастью команда по продукту продумала такие вопросы и создала некоторые параметры конфигурации для настройки резервного копирования.
Данный материал является переводом оригинальной статьи "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 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
Таким образом, чтобы успешно изменить параметры реестра в этом ключе, нам потребуется выполнить некоторую последовательность действий.
Здравствуйте, Игорь. Процедура, описанная в статье, теоретически применима и для Windows Server 2019. Ошибка с кодом 87 "Параметр задан неверно"…
Добрый день. Подскажите пожалуйста, а на Windows Server 2019 есть какие-то особенности по данной процедуре? почему-то по инструкции не сработало.…
RSS - Записи
Последние комментарии