Один дизайн, используемый для каждого клиента. Специфические для облака различия — продукт для подключения, ключевая услуга, механизм базы данных — это варианты конфигурации, а не перепроектирование. Именно это позволяет создать среду из кода за пять рабочих дней.
Читая картинку сверху вниз
- Пользователи и интеграции получают доступ к одному имени, erp.<домен клиента>, и взаимодействуют с балансировщиком нагрузки с WAF по протоколу HTTPS, TLS 1.2 или выше. Это единственный общедоступный способ подключения.
- Для работы веб-интерфейса и API, механизма обработки запросов, оператора ASK, а также рабочих процессов и заданий необходимо как минимум три рабочих узла (по одному на каждую зону доступности). Потеря одного узла или целой зоны приведет к сокращению ресурсов, обслуживающих пользователей.
- Управляемая база данных — с выбранным клиентом механизмом и размером — имеет синхронный резерв в другой зоне. Сбой зоны ничего не теряет: RPO ≈ 0.
- Документы и вложения хранятся в версионированном объектном хранилище, а не в базе данных.
- Исходящий трафик проходит через NAT к разрешенному списку: банки, налоговая служба и электронное выставление счетов, расчет заработной платы, электронная почта, система искусственного интеллекта. Ничего больше.
- Резервные копии передаются в одном направлении — в изолированное хранилище в отдельном аккаунте.
Закрытая конечная точка и внутренний балансировщик нагрузки обозначены пунктиром, поскольку они существуют только при использовании закрытого доступа. При доступе только по HTTPS они не создаются.
Пять регуляторов, и больше ничего.
Размер узлов; количество узлов (минимум три); тип и размер базы данных; регион Live DR; количество сред. Все остальное — это эталонная архитектура.
Настройте, интегрируйте, и только потом пишите код.
Требование, выходящее за рамки стандарта, выполняется путем конфигурации, если это возможно — путем обновления с помощью платформы. В противном случае — путем интеграции через API TRANXACT, работающие вне кластера. Только после проверки безопасности и технических характеристик рассматривается код или агент внутри кластера; если одобрение получено, это допускается и поддерживается клиентом, а если отклонено — запускается вне кластера.
Для клиента нет прямого доступа к базе данных — он помечен как недоступный (DB_3.1.09). Отчетность и интеграция осуществляются через API и извлечения данных TRANXACT, поэтому инструмент бизнес-аналитики подключается через API или запланированные извлечения, а не через вход в базу данных.
Команда бизнес-аналитики Calderwood запрашивает пользователя с правами только для чтения к их хранилищу данных. Решение — запланированное извлечение данных по частной ссылке: в списке интерфейсов команды BI указано «сохранить, запланированное извлечение, частная ссылка».
Попробуйте! В конце месяца в Калдервуде произошел сбой одного из рабочих узлов в зоне 2. Что произойдет с пользователями, и будет ли это учитываться в рамках соглашения об уровне обслуживания (SLA)?
Его модули перенаправляются на узлы в зонах 1 и 3, которые были рассчитаны на эту нагрузку; база данных остается неизменной, за исключением случаев, когда основной узел находится в зоне 2, в этом случае происходит переключение на синхронный резервный узел с RPO ≈ 0. Это учитывается в рамках SLA только в том случае, если доступность за месяц не соответствует целевому показателю уровня.