Обзор архитектуры/плана масштабирования
Преимущества:
- Предоставление документации
- Повышение знаний об архитектуре
- Планирование будущих развертываний
Цель
Задача состоит в том, чтобы получить задокументированные архитектурные схемы Qlik для n и n+1 развертываний *, а также понять высокоуровневые архитектурные концепции в Qlik.
* n относится к текущему развертыванию, а n+1 относится к состоянию предполагаемого следующего развертывания.
Это необходимо, чтобы:
- иметь понимание о развертывании системы, и как его производить
- планировать рост
- представлять требуемые изменения
- разобраться с параметрами отказоустойчивости и доступности
- предоставить доступ к документации для других специалистов
Сопутствующая документация
Пожалуйста, найдите время, чтобы просмотреть темы, описанные ниже, если вы еще не знакомы с ними, прежде чем продолжить читать эту статью.
- Архитектура 101 (Компоненты, Терминология)
- Концепции балансировки нагрузки
- Отказоустойчивость и высокая доступность
- Примеры производственной архитектуры
Построение архитектурной схемы
Основные требования
- Редактор. Это может быть Visio, PowerPoint или веб-редакторы, такие как Gliffy и Draw.io.
- Набор базовых значков или символов
- Если развертывание локальное
- сервер
- база данных
- файловый ресурс
- балансировщик сетевой нагрузки
- Если развертывание проходит в облаке:
- Знание того, какие сервисы Qlik активны на каких узлах.
- Знание того, для чего используется каждый узел Qlik.
- Знание того, где находится файловый ресурс Qlik и база данных репозитория Qlik.
Будет хорошо иметь в своем распоряжении
- Имена и псевдонимы серверов
- Любые балансировщики сетевой нагрузки / интерфейсы, предшествующие Qlik.
- Любые настройки брандмауэра, относящиеся к Qlik.
Пример схемы для локального размещения
Среда роста
Корпоративная среда
Пример схемы для размещения на AWS
Корпоративная среда
Примечание
Обратите внимание, что эти облачные диаграммы предназначены для администраторов Qlik и иногда используются для перевода потребностей в поддержку таких бизнес-объектов, как ИТ. Приведенные ниже примеры не соответствуют стандартам архитектурных схем отдельных поставщиков облачных вычислений, поскольку они не предназначены для использования инженерами облачных вычислений/администраторами сети и т. д. Если требуется включить в схему VPCs, AZs, SGs, Network ACLs, тем лучше - но этот вопрос выходит за рамки основ этого поста.
Примечание
Файловый SMB - либо FSx (требуется домен), либо EBS хранилище на инстансе EC2.
Примечание
Можно также использовать Growth Environment в AWS, одновременно с базой данных хранилища и общим доступом к файлам на экземпляре AWS EC2.
Пример схемы для размещения на Azure
Корпоративная среда
Примечание
Обратите внимание, что эти облачные диаграммы предназначены для администраторов Qlik и иногда используются для перевода потребностей в поддержку таких бизнес-объектов, как ИТ. Приведенные ниже примеры не соответствуют стандартам архитектурных схем отдельных поставщиков облачных услуг, поскольку они не предназначены для использования инженерами облачных вычислений/администраторами сети и т. д. Если требуется включить в схему VPCs, AZs, SGs, Network ACLs, тем лучше - но этот вопрос выходит за рамки основ этого поста.
Примечание
Файлы Azure для хранилища SMB с помощью Cmdkey или диспетчера учетных данных Windows (Windows Credential Manager).
Примечание
Можно также использовать Growth Environment в Azure, одновременно с базой данных хранилища и общим доступом к файлам на виртуальной машине Azure.
Планирование архитектур N+1
Чтобы спланировать предстоящее архитектурное изменение, необходимо иметь представление о различных методах масштабирования сайта, а также о любых архитектурных воздействиях, которые может иметь текущий План производительной мощности.
Концепции масштабирования высокого уровня
Вообще говоря, есть две основные методологии масштабирования, но стоит обратить внимание на тот факт, что они не исключают друг друга:
- Горизонтальное масштабирование
- Добавление дополнительных узлов/служб, обеспечивающих широкую, устойчивую топологию.
- Вертикальное масштабирование
- Расширение текущей мощности сервера, то есть добавление дополнительных ядер/ОЗУ.
Горизонтальное масштабирование обычно используется в том случае, если в среде Qlik есть приложения малого и среднего размера с большим количеством пользователей. Это означает, что приложения можно быстро загружать на множество различных узлов с небольшой задержкой, а вычисления выполняются быстро, и это означает, что общий кеш не обязательно является значимой частью этих приложений. Эта методология также распространена в виртуальных средах в том случае, если размеры виртуальных машин могут быть ограничены. Например, если организация ограничивает размеры виртуальных машин 96 или 128 ГБ ОЗУ, более чем вероятно, что среда Qlik в конечном итоге займет более обширное пространство и примет методы, позволяющие своим приложениям соответствовать ей.
Вертикальное масштабирование обычно встречается там, где пользовательская база невелика, а приложения довольно большие. Меньшее количество узлов с большей емкостью дает доступ для более крупных приложений с большим количеством пользователей, использующих один и тот же кеш. Кэш этих приложений обычно подогревается, поэтому они становятся доступными для пользователей сразу же.
Обе эти методологии часто комбинируются, когда в организации используются как очень большие приложения, так и приложения меньшего размера с широким пулом пользователей. Обычно организации имеют «малые-средние модели приложений» и «большие модели приложений», например, четыре первых и два вторых. Используя правила балансировки нагрузки (как описано в разделе «Обзор закрепления/балансировки нагрузки»), большие приложения «прикрепляются» к более крупным узлам, и наоборот.
Обзор плана производительной мощности
Чтобы спланировать следующее архитектурное изменение, необходимо сначала просмотреть текущий план производительной мощности.
Общие вопросы, которые могут повлиять на ход процесса:
- Произойдет ли значительное увеличение количества лицензий, которое потребует дополнительных узлов прокси и/или ядер ЦП?
- Постоянно ли находятся показатели ЦП/ОЗУ в работоспособном состоянии на всех узлах системы, предназначенных для конечных пользователей? В противном случае это может служить основанием для вертикального роста или оптимизации приложения.
- Выполняются ли обновления приложений на узлах конечных пользователей в течение дня, и как они влияют на производительность, а, следовательно, на удобство работы конечного пользователя? Это может служить основанием для переноса их на выделенный планировщик (Qlik Scheduler) (это настоятельно рекомендуется и предпочтительно).
- Существуют ли приложения, которые рассматриваются для «привязки приложений» к конкретным узлам с помощью правил балансировки нагрузки? Может ли оптимизация приложений уменьшить размер этих приложений, чтобы избежать этого, или они будут просто монолитны по своей природе и должны ли они быть закреплены? Достаточно ли в настоящее время узлов для поддержки разделения активов при обеспечении отказоустойчивости (2+ узла для каждого), или нужно больше узлов? Требуется ли вертикальный рост для поддержки этих больших приложений на меньшем количестве узлов, учитывая тот факт, что потенциально на меньшем количестве узлов будет больше кэширования пользователей?
- Предпочтителен ли горизонтальный рост, или вертикальный рост, или какое-то бизнес-событие стимулирует тот или иной рост? Возможно ли сочетание того и другого? Это потребует обсуждения с ИТ-отделом, чтобы увидеть, что возможно.
- Является ли что-то вне развертывания Qlik движущим архитектурным событием, например, сейчас есть деньги, которые нужно потратить на инфраструктуру, а лицензирование может подождать еще 6 месяцев? Это потребует обсуждения с представителями бизнеса, чтобы узнать, какие типы приложений/вариантов использования находятся в стадии разработки, и чтобы увидеть, какая инфраструктура должна поддерживать будущие потребности.
- ODAG используется или будет использоваться? Должны ли обновления приложений ODAG происходить на выделенном планировщике?
- Qlik NPrinting или Qlik InsightBotot есть или планируются? Должны ли они работать на выделенных движках (Qlik Engine)?
Все эти вопросы, следует учитывать при планировании архитектуры следующего состояния.
