Руководство по обновлению до версии Data Center
Не существует двух одинаковых организаций. Ваша миграция тоже будет отличаться от других. Следуйте нашему пошаговому руководству по обновлению, чтобы без проблем перейти с версии Atlassian Server на Data Center.
Оценка
У каждой организации уникальные потребности и требования. Для планирования успешного обновления необходимо сравнить альтернативы с учетом своих ожиданий.
Определение требований к архитектуре и инфраструктуре
Выбрали Data Center? Тогда узнайте больше о поддерживаемой архитектуре и конфигурациях развертывания этой версии.
Существует два способа развертывания Data Center: некластерный и кластерный. Оба позволяют пользоваться корпоративными функциями и возможностями, но у каждого есть свои особенности. В таблице вы найдете отличия некластерной и кластерной архитектур:
Некластерная архитектура рекомендуется
Требования к архитектуре
Некластерная архитектура позволяет обновить версию до Data Center в существующей инфраструктуре и не требует ее изменения.
Когда рекомендуется
Всем нашим клиентам рекомендуется выполнять переход на Data Center в некластерной среде. При необходимости внедрить кластерную архитектуру можно сразу после перехода на Data Center.
Преимущества
Откройте для себя корпоративные возможности, которые не зависят от кластеризации.
Как правило, многие клиенты начинают работу с некластерной версией Data Center. Мы рекомендуем воспользоваться этим 2-минутным обновлением, чтобы обеспечить плавный переход.
Кластерная архитектура
Всем нашим клиентам рекомендуется сначала выполнить переход на Data Center в некластерной среде. После успешного обновления до Data Center при необходимости можно внедрить кластерную архитектуру.
Требования к архитектуре
Для обновления до версии Data Center в кластере необходимы следующие компоненты:
- Балансировщик нагрузки
- Узлы приложений
- Файловая система, которая доступна для всех узлов приложений
- Узел Elasticsearch (Bitbucket)
Когда рекомендуется
- Вам нужна высокая доступность
- Вы хотите выполнять обновления без нарушения работы
- Вскоре ожидается значительный рост организации
Преимущества
Откройте для себя корпоративные функции, которые может предоставить кластеризация:
- Корпоративные функции и возможности
- Высокая доступность и защита от сбоев: если один из узлов кластера приложений выходит из строя, нагрузка перераспределяется между другими, и продукт остается доступным для пользователей.
- Мгновенная масштабируемость: добавляйте новые узлы в кластер без простоев и дополнительных расходов на лицензирование. Индексы и приложения синхронизируются автоматически.
- Аварийное восстановление: разверните удаленную систему аварийного восстановления, чтобы обеспечить непрерывность бизнеса даже в случае полного выхода систем из строя. Совместное использование индексов продуктами позволит быстро восстановить работу.
Планирование и подготовка
Вы выбрали алгоритм перехода на Data Center и теперь готовы начать подробное планирование обновления.
Составьте график Обязательно
Следующие приблизительные сроки позволят вам оценить, сколько времени займет обновление.
| | Некластерная архитектура | Кластерная архитектура |
|---|---|---|
| Планирование | Некластерная архитектура до 2 недель | Кластерная архитектура от месяца |
| Тестовая миграция | Некластерная архитектура до недели | Кластерная архитектура 3–6 месяцев |
| Запускайте в рабочей среде | Некластерная архитектура до недели | Кластерная архитектура ~6–9 месяцев |
Указанные сроки основаны на опыте наших клиентов, которые успешно прошли обновление до версии Data Center. Следует учитывать, что реальные сроки могут отличаться в зависимости от индивидуальных особенностей вашей среды, в том числе ее размера, сложности и степени готовности.
Определение среды Data Center Обязательно
Уровень приложений
Экземпляры и местоположения
- Вы хотите интегрировать или консолидировать экземпляры?
- Как вы оцениваете перспективы роста?
- Нужна ли вам изоляция данных?
- Сколько сред использует ваша команда (например, промежуточных или рабочих)?
Профили экземпляров
- Сколько пользователей будут иметь доступ к экземпляру?
- Где будут находиться ваши команды?
- Какой объем данных находится в экземпляре сейчас и сколько данных вы планируете добавить?
Приложения, интеграции и индивидуальные настройки
Нужны ли они все или можно упростить систему?
Уровень инфраструктуры
Размер экземпляра
- Каковы ваши прогнозы относительно роста?
- Бывают ли периоды снижения пользовательского трафика?
Подробнее см. в кратком описании выбора оптимальной конфигурации узлов.
Структура аккаунтов
- На каких аккаунтах будет выполняться развертывание среды?
- Нужны ли вам отдельные аккаунты для каждой из сред?
- Нужно ли вам, чтобы в продуктах Data Center использовался тот же аккаунт, что и в инструментах CI/CD или инструментах для совместной работы?
Модель управления
- Какова ваша модель управления?
- Каковы минимальные стандарты системы?
- Централизовано ли ведение журналов?
- Каковы ваши потребности в управлении пользователями?
Рассмотрите возможность использования в рамках своей модели управления AWS Landing Zone и AWS System Manager.
Виртуальное частное облако
-
Хотите ли вы использовать новое виртуальное частное облако (VPC)?
Если вы хотите выполнить развертывание в новом облаке VPC или использовать уже существующее, можете воспользоваться шаблоном Atlassian Standard Infrastructure (ASI).
- Нужно ли изменить какие-либо основные сетевые настройки, например ограничить общий доступ в Интернет или изменить внутреннюю IP-адресацию для маршрутизации офисных сетей и VPN?
- Обязательны ли сертификаты TLS?
Регион
-
Если вы решили использовать существующее облако VPC, то разработан ли план доступа из офисной сети и VPN?
Рекомендуется разрешить доступ из всех офисных сетей и VPN, так как масштаб использования продукта, скорее всего, вырастет со временем.
Direct Connect
- Хотите ли вы использовать Direct Connect для повышения производительности и безопасности?
- Какой объем данных необходимо перенести из экземпляра Server в Data Center?
Для переноса большого количества данных можно использовать группу сервисов AWS Snow.
Непрерывная работа бизнеса и аварийное восстановление
Резервная копия
Какова ваша стратегия резервного копирования?
Рекомендуется использовать существующую стратегию резервного копирования в сочетании со встроенными возможностями AWS. Подробнее см. на страницах:
Инфраструктурные сервисы AWS менее подвержены единичным отказам.
Аварийное переключение регионов
Нужны ли вам узлы восстановления с «холодным», «теплым» или «горячим» резервированием в разных регионах?
Как правило, для аварийного восстановления достаточно того, чтобы сервисы работали в нескольких зонах доступности, но вы также можете уменьшить последствия отказов на уровне региона. Принимая решение о реализации узлов восстановления в разных регионах, учитывайте следующее.
- Стоимость инфраструктуры и передачи данных
- Скорость восстановления по сравнению с AWS
- Затраты времени на техническое обслуживание и тестирование узла восстановления
- Стоимость эксплуатации узла восстановления
Обновление до версии Data Center (некластерной) рекомендуется
Всем нашим клиентам рекомендуется выполнять переход на Data Center с некластерной архитектурой. Некластерные обновления — это более быстрый и простой вариант, обеспечивающий ускоренный доступ к безопасности, поддержке и корпоративным функциям Data Center.
Обновление до версии Data Center (кластерной) не рекомендуется
Лучше не выполнять обновление до Data Center сразу на кластерной архитектуре из-за сложности такого перехода. Всем нашим клиентам рекомендуется сначала выполнить переход на Data Center в некластерной среде. После этого клиенты, которым необходима кластерная архитектура, могут приступить к ее внедрению.
После обновления до Data Center с некластерной архитектурой можно внедрить кластерную, если вам требуется высокая доступность.
Выстраивание инфраструктуры для кластера
Для развертывания версии Data Center в кластере необходимы следующие компоненты:
- База данных
- Балансировщик нагрузки
- Узлы приложений
- Совместно используемая файловая система
- Узел Elasticsearch (Bitbucket)
Балансировщик нагрузки
При развертывании в кластере все запросы пользователей сначала направляются на балансировщик нагрузки, который распределяет их по узлам приложений. Вы можете использовать аппаратный или программный балансировщик нагрузки. В обоих случаях балансировщик нагрузки должен быть связан с кластером приложений через высокоскоростное соединение по локальной сети с высокой пропускной способностью и низким значением задержки. Программные балансировщики необходимо устанавливать на выделенные машины.
Продукты Data Center предусматривают направление запросов каждого пользователя на один и тот же узел в течение сеанса. Если запросы будут направлены на разные узлы, пользователя может «выбросить» из системы. При этом сохраненные в сеансе данные могут быть потеряны. Поэтому каждый сеанс должен выполняться на одном узле. Для этого нужно включить функцию «закрепления сеансов» на основе cookie-файлов (привязка сеансов) на балансировщике нагрузки. Для закрепления сеансов могут использоваться как cookie-файлы, созданные продуктами, так и cookie-файлы, генерируемые балансировщиком нагрузки.
Повысьте отказоустойчивость, установив резервный балансировщик нагрузки для подстраховки на случай отказа главного балансировщика. Пару балансировщиков нагрузки можно эксплуатировать в конфигурации «активный/пассивный», назначив один виртуальный IP-адрес обоим балансировщикам. При отказе активного балансировщика произойдет аварийное переключение на пассивный.
Подробнее см. на странице параметров конфигурации балансировщика нагрузки.
Узлы приложений
На узлах приложений размещаются и работают продукты. Все продукты, запускаемые на узлах кластера Data Center, должны быть одной версии. Узлы должны находиться в одном месте для снижения значения задержки. Однако при наличии географически распределенных команд вы можете использовать сеть доставки контента (CDN). Узлы должны быть скомпонованы в кластер и работать как единое целое для поставки продукта пользователям. Количество узлов в кластере зависит от ваших потребностей и конфигурации продукта. Для большинства кластеров бывает достаточно от двух до четырех узлов, но вы можете воспользоваться нашими руководствами по определению оптимальной конфигурации узлов, чтобы оценить точнее.
Для Bitbucket необходим дополнительный узел приложения, специально выделенный под систему Elasticsearch, которая позволяет выполнять поиск по коду.
Совместно используемая файловая система
В совместно используемой файловой системе хранятся данные, которые должны быть доступны для любого узла приложения, например вложенные файлы и репозитории Git.
В среде Data Center совместно используемая файловая система должна находиться на отдельном узле. Для работы совместно используемой файловой системы можно использовать любые программы NAS или SAN на основе NFS, но для поддержки высокой производительности рекомендуется использовать NFS3. Не используйте DFS и другие распределенные протоколы, поскольку они не поддерживаются.
Создание раздела проиндексированных файлов
Для успешного перехода на несколько узлов рекомендуется создать промежуточную среду и испытать в ней Data Center, прежде чем запускать эту версию в рабочей среде.
Раздел проиндексированных файлов должен в точности повторять рабочую среду, включая использование обратных прокси-серверов, конфигурации SSL и балансировщика нагрузки. Можно использовать другой физический или виртуальный сервер. Главное, чтобы копия рабочей среды была достаточно точной.
Подробные инструкции см. по следующим ссылкам.
Консультация с экспертом
Хотите задать вопрос о вариантах или стратегии миграции? Получите рекомендации от нашей команды специалистов по миграции.