`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Что для вас является метрикой простоя серверной инфраструктуры?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

ИТ-пятница с GigaCloud. Сессия 8

+33
голоса

На восьмой сессии технических семинаров, известных как «ИТ-пятницы с GigaCloud», были рассмотрены такие темы, как кластеризация 1С, онлайн-мониторинг сервисов с помощью чат-ботов и инфраструктура Veeam.

Для эффективной работы 1С система должна обладать такими свойствами, как доступность и устойчивость. Как того можно достигнуть с помощью кластеризации на уровне сервера приложений, рассказал ведущий инженер биллинга Константин Баштовый из GigaGroup.

ИТ-пятница с GigaCloud. Сессия 8

Константин Баштовый: «Чем выше уровень отказоустойчивости, тем больше система тратит ресурсов на резервирование всех сессий»

Чтобы разобраться с этим, необходимо создать стандартную среду для типичной небольшой компании из терминального сервера, либо фермы терминалов, за которыми работают клиенты, двух серверов приложений для 1С и сервер БД. Необходимо сконфигурировать все таким образом, чтобы все узлы были отказоустойчивыми.

Для начала создаются виртуальные или физические сервера на площадке компании или в облаке. Два сервера служат в качестве серверов приложений, и в одном из них поднимается кластер 1С. Кластер может содержать центральный сервер, который принимает входящие соединения (к нему непосредственно могут подключаться клиентские приложения) либо рабочий север, который не принимает соединения, но он участвует в балансировке нагрузки.

Одним из самых важных параметров является уровень отказоустойчивости. Он указывается в свойствах кластера. Параметр указывает максимальное количество серверов, которые могут отказать, но при этом кластер останется работоспособным. К примеру, пусть кластер содержит три сервера — один центральный и два рабочих. При уровне отказоустойчивости «1» один сервер может отказать. Если отказал один из рабочих серверов, то кластер остается работоспособным, все сессии резервировались, и в идеальном случае клиент практически ничего не заметит. Если отказывают два рабочих сервера, то кластер все же доступен. Но в этом случае превышен уровень отказоустойчивости. Как результат все клиентские сессии на этих рабочих серверах будут потеряны. Однако пользователи могут переподключиться к центральному серверу. При отказе центрального сервера кластер становится полностью недоступен. Из этого следует вывод, что чем выше уровень отказоустойчивости, тем больше система тратит ресурсов на резервирование всех сессий. Например, в случае кластера из пяти серверов при уровне отказоустойчивости «1» допускается отказ только одного узла.

Затем докладчик остановился на такой функции, как блокировка, которая выполняется при конкуренции за ресурс. При превышении времени ожидания ресурса параллельная работа пользователей нарушается. Что предлагает 1С? В системе есть два типа блокировок — объектные и транзакционные. Первый позволяет осуществлять конкурентный доступ пользователей к данным 1С:Предприятия в терминах объектов информационной базы. Как правило в большинстве случаев это связано с интерактивной работой пользователей в формах: редактирование существующих объектов, удаление, создание новых и др. Что касается второго механизма, то он применяется для согласования изменения данных в БД.

Таким образом, сервер 1С:Предприятие отвечает не просто за соединения между клиентским приложением и сервером БД, но и за разделение доступа к данным.

Полезным инструментом является мониторинг сервисов в режиме реального времени. Для этого можно использовать чат-боты, или мессенджеры, с помощью которых можно выполнять мониторинг обширного парка серверов и сетевого оборудования, приняв во внимание, что все мессенджеры поддерживают API. Об этом рассказал системный администратор Андрей Железняк, взяв в качестве примера Telegram Bot API.

ИТ-пятница с GigaCloud. Сессия 8

Андрей Железняк: «Для мониторинга сервисов в режиме реального можно использовать чат-боты или мессенджеры»

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

Мессенджеры позволяют не только получать уведомления, но и осуществлять общение как с самим мессенджером, так и с сервисом, который за ним стоит, через службу API. Асинхронность обмена установлена по умолчанию, синхронность можно установить по необходимости. Мессенджер отдает команду, и ее обработка происходит следующим образом. Сначала выполняется верификация пользователя, затем определяется, есть ли код, связанный с этой командой, и затем выполнение кода. Результат, если это предусмотрено, вернется в мессенджер. Что касается времени на разработку и внедрение, то практически все API в мессенджерах очень подробно документированы. Далее докладчик привел пример логики на основе log-js, при этом основная логика и код самого бота были написаны JavaScript. Так было сделано, поскольку парк серверов и список сервисов довольно обширен, они находятся на достаточном удалении друг от друга, и ответы от них могут приходить в разной очередности, а JS позволяет выполнять весь код асинхронно.

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

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

Для реализации данного сервиса и доступа извне на коммутационном оборудовании не понадобится открывать никаких входящих портов, то есть брандмауэры могут быть закрыты. Необходим только выход наружу от одной машины по протоколу HTTPS на определенный набор IP-адресов.

Что касается авторизации, то можно реализовать собственный механизм на основе информация об идентификации от сервиса API, которую предоставляет chat ID. Дополнительная безопасность обеспечивается выполнением кода исключительно на стороне пользователя, он не выгружается на внешние ресурсы, и API вообще о нем ничего не знает.

Резервирование является хрестоматийным методом защиты данных. Обычно оно выполняется ночью, вне бизнес-времени. Что, если нужно сделать не одно резервирование, и не два, а, скажем, 100? Этим «секретом» поделился руководитель отдела R&D GigaCloud Кирилл Науменко.

ИТ-пятница с GigaCloud. Сессия 8

Кирилл Науменко: «Одним из основных компонентов в процессе резервирования является прокси-сервер, который перемещает данные»

Впоследствии он уточнил проблему. Речь пойдет не просто о 100 резервных копий, а о 100 заданиях, которые выполняются на трех площадках, семи СХД разных типов, в разные репозитории и с помощью VMware.

Обычно резервирование осуществляется следующим образом. Есть хосты, есть слой виртуализации, есть ВМ. Это продуктивная среда, в которой выполняются сервисы и работают ВМ клиентов. Есть производственные СХД. Когда выполняется резервное копирование, существует некий прокси-сервер, который с помощью Data Mover перемещает данные из производственной среды в репозиторий резервных копий.

Какие основные компоненты у Veeam? Это сервер резервирования в качестве управляющего компонента инфраструктуры, прокси-сервер, который обрабатывает и передает данные, и репозиторий резервных копий. По умолчанию Veeam установит все три компонента на одном сервере. При подключении VMware все заработает сразу. Ситуация усложняется, если начать резервировать две, три и более машин, и делать это отдельными заданиями. В этом случае ресурсов может не хватить. Требования, вообще говоря, зависят от того, что необходимо резервировать. Учитывая, что все три компонента обычно разворачиваются в Windows-средах, то для эффективной работы может понадобиться крупная инфраструктура провайдера.

Далее выступающий привел конкретные примеры допустимых настроек для улучшения условий резервирования. Одним из основных компонентов в этом процессе является прокси-сервер резервирования, который будет перемещать данные. Основной его функциональностью является режим работы. Их существует три: Direct Storage Access, Virtual Appliance и Network Mode. Первый режим автоматически выбирает наилучший способ. При каких-то затруднениях можно перейти в режим Network Mode. При этом нужно помнить, что он также является интерфейсом управления и не должен быть перегружен.

Новая журналируемая файловая система Windows ReFS очень эффективно выполняет синтетические полные копии. Эти копии объединяют все инкременты в единую полную копию. Это позволяет экономить файловое пространство, не копировать блоки, а просто изменять метаданные и делать ссылки.

Что касается сервера резервирования, то там не так много настроек, но существует Storage Latency Control, который позволяет ограничивать количество заданий (job) по латентности. Существует также ограничение моментальных копий на одну продуктивную СХД. Veeam полагает, что если на одной такой СХД создается более четырех моментальных копий, то есть риск того, что «дельта», которая записывается в эту копию, может переполнить СХД.

Говоря о заданиях, Кирилл Науменко отметил, что структуру выполнения резервных копий можно задать по-разному, что влияет и на производительность, и на квоту, а следовательно, и на цену. Однако есть режим, который экономит квоту. Это Forever Forward Incremental Backup, при котором вообще не создаются полные копии. Полная копия делается только один раз, а потом добавляются только инкременты. При создании восьмого инкремента первый объединяется с полной копией.

Выступление завершилось обзором возможностей Veeam Backup Enterprise Manager, компонентом управления и отчетности, который позволяет управлять несколькими инсталляциями Veeam Backup & Replication из одной веб-консоли. Он предоставляет ролевую модель управления, определяя разным администраторам разные права, квоты и управляемые ВМ; порталы самообслуживания, которые доступны и администраторам и клиентам, на которых последние могут создавать резервные копии, настраивать планировщик заданий, включать уведомления по резервным копиям и управлять восстановлением своих машин.

Следующая встреча в рамках «ИТ-пятницы с GigaCloud» состоится 24-го мая. Организаторы приглашают к участию слушателей и докладчиков. Для этого необходимо зарегистрироваться

 

 

+33
голоса

Напечатать Отправить другу

Читайте также

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT