что такое обновление сервера

Обновление кода приложений на работающем сервере

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

Чтобы лучше понимать масштаб данных операций, просто представьте, что банк не смог осуществить многомиллионный платеж клиента или что какая-либо из диспетчерских систем аэропорта «Хитроу» решила обновиться во время взлета самолета. Едва ли подобный сценарий допустим в сегодняшних реалиях.

Тем не менее, сервера приложений неизбежно приходится обновлять – никуда от этого не деться. А с учетом постоянной нагрузки на них вопрос бесперебойности работы приложений во время обновлений становится как никогда актуальным.

Что необходимо для обеспечения бесперебойной работы приложений во время обновления?

Существует несколько способов решения данной проблемы:

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

Кому может быть интересно такое решение?

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

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

Особенности разработки сложных приложений

Одним из принципов разработки сложных приложений является построение модульных приложений, модули в которых слабо связаны. В мире Java подобную технологию хотели включить еще в JDK 7, позже решили выпустить ее вместе с Java 8, но теперь, судя по текущим анонсам, она появится уже не ранее чем с Java 9 в марте 2017 года как механизм взаимодействия модулей Jigsaw.

Благодаря принципу модульности подобные приложения можно обновлять в процессе их работы даже под нагрузкой. Те, кто не хочет дожидаться выхода свежих версий Java, могут воспользоваться модульным подходом для разработки приложений уже сейчас – технология носит название OSGi, ее первая спецификация появилась еще в начале 2000-х годов. Обновление кода приложений под нагрузкой без кластеризации может быть применимо как для PC, так и для мобильных устройств. Более того, это требует меньше ресурсов (процессорных, памяти, диска) и меньших временных затрат на настройку и тестирование.

А как же облака?

В связи с возрастающей популярностью облачных сервисов нельзя не затронуть и эту тему.
Для решения проблемы с обновлением действительно можно создать виртуальный IP-адрес, настроить балансировку с него на несколько узлов приложения и обновлять их последовательно. При этом в системе будут одновременно существовать приложения разных версий. Это возможно с учетом продуманного дизайна приложений, однако накладывает на них дополнительные требования. По сути, должна быть обеспечена полная независимость приложений от данных, они не должны сохранять состояние и должны быть спроектированы так, чтобы было допустимо наличие различных версий в системе. Фактически это предполагает одновременную работу нескольких приложений, что накладывает дополнительные расходы на управление ими. Следует, однако, отметить, что облачные технологии и OSGi не являются взаимоисключающими. Подходы OSGi можно использовать и в облаках, что, помимо прочего, предполагает абстракцию от железа.

Таким образом, использование облачных серверов позволяет как разбивать модули приложения на отдельные узлы облака по принципу OSGi, так и запускать полноценное приложение со всеми модулями на каждом узле, создавая при этом избыточность. Какой из этих способов выбрать, зависит в первую очередь от ресурсов организации.

Каковы основные отличия спецификации OSGi от Jigsaw?

Само собой, чтобы понимать целесообразность использования спецификации OSGi с учетом грядущего обновления Java, следует разобраться, чем данные решения будут различаться и будут ли они совместимыми. Давайте рассмотрим таблицу ниже:

В базовом режиме совместимости фреймворк и наборы OSGi будут полностью существовать в пределах «безымянного» модуля Jigsaw. OSGi будет и в дальнейшем предлагать весь свой функционал по изоляции – наряду с мощным реестром и динамической загрузкой. Любые вложения в OSGi являются безопасными, так как спецификация по-прежнему останется хорошим вариантом для любых новых проектов.

В чем особенность работы со спецификацией OSGi?

Спецификация OSGi основана на использовании модульных приложений, компоненты которых работают в слабосвязанной среде, а маршруты взаимодействия между приложениями настраиваются в конфигурационном файле. Подобная модель приложения позволяет рассматривать его как сеть (граф), где узлы – компоненты, а ветви – связи между ними. При этом связи могут быть как односторонними, так и двухсторонними.

При обновлении кода подобной программы в первую очередь необходимо проанализировать следующие моменты:

Работают они следующим образом: в слабосвязанной среде существует энное количество модулей, которые могут взаимодействовать между собой либо с помощью сервисов, либо с помощью сообщений, либо с помощью и тех и других. Во время обновления конкретного модуля сообщения будут накапливаться в очереди, а сервисы будут ожидать на половине пути, пока модуль назначения не обновится.

Анализ сервисов проводится посредством открытой реализации фреймворка OSGi, а анализ сообщений – с помощью прикладного кода (в нашем случае приложения Real Time Framework (RTF), речь о котором пойдет ниже). Это позволяет понять, в каких точках маршрута взаимодействия компонентов необходимо временно накопить в очереди сообщения (с помощью которых взаимодействуют компоненты) или временно приостановить вызываемые сервисы, чтобы сразу после обновления прикладного кода приложения можно было продолжить работу. В результате, пока код приложения будет обновляться до следующей версиии, сообщения будут накапливаться в очереди, а сервисы будут поставлены в режим ожидания, то есть на время обновления затронутые маршруты станут недоступны. Таким образом, сервер приложений не потребуется перезагружать, что позволит значительно уменьшить время недоступности приложений. Кроме того, не нужно снова загружать кэши, так как приложение продолжит работу ровно с того места, где приостановилось на время обновления.

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

Помимо этого, необходимо отделять API от реализации, чтобы можно было проще обновлять ее, не затрагивая API. Зачем? Для сравнения: сервер приложений обычно стартует за минуты, в идеальном случае – за 20–30 секунд, а обновление компонента в работающем сервере будет занимать всего 2–5 секунд, при этом все служебные данные не нужно будет снова загружать в память (кэш).

Приложение Real Тime Framework (RTF) для обновления кода под нагрузкой

RTF – это коммерческий продукт Netcracker на базе спецификации OSGi, который является приложением, состоящим из модулей. Сама спецификация OSGi предоставляет лишь возможность параллельно иметь несколько версий работы многих модулей, связанных определенными зависимостями, а вот построение синхронных и асинхронных связей между модулями и работа по обновлению компонентов находится в компетенции самого приложения RTF.

Особенность RTF в том, что он расширяет возможности OSGi, позволяя не только обновлять исходный код приложения во время работы, но и делать это под нагрузкой. Другими словами, он позволяет «поставить приложение на паузу», обновить и продолжить выполнение запросов в штатном режиме уже на обновленном приложении.

Он также предоставляет легковесный транспорт для отправки и приема сообщений между компонентами, реализованный на Java без сохранения сообщений в какую-либо базу данных. Подобный транспорт позволяет организовать взаимодействие компонентов в распределенной системе слабо связанных компонентов. Проиллюстрировать механизм взаимодействия компонентов можно с помощью схемы ниже:

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

Примеры использования RTF

Технология RTF не нова и уже не раз доказывала свою эффективность. Одним из примеров является настройка биллинговых сервисов «с нуля» для компании Axia на основе приложения RTF. Имплементация была выполнена standalone, т. е. без использования возможностей кластеризации. В данном случае Компании было как никогда важно обеспечить стабильную работу системы даже во время обновления каких-либо компонентов, так как специфика обработки платежей не позволяет допускать ни малейших ошибок или задержек в работе.

В последнее время большое количество разработок ведется для MANO (Management and Orchestration). В данном случае технология RTF применяется для работы системного монитора (следит за состоянием «железа») и монитора виртуализации сетей (VNF). Стоит отметить, что все работы ведутся в open stack, что еще раз подтверждает полную совместимость технологии RTF с облачными сервисами. В качестве примера стоит привести работу NEC/Netcracker по виртуализации сетей для японского оператора связи NTT DOCOMO. Этот проект дает компании возможность гибко изменять мощность базовой сети, а также позволяет значительно сократить время восстановления в случае сбоя оборудования.

Выводы

В статье продемонстрирован один из возможных способов обновления кода приложения на работающем под нагрузкой сервере – на примере коммерческого сервера приложений RTF, который соответствует спецификации OSGi. RTF позволяет приостановить взаимодействие модулей, из которых состоит приложение, поставить все сообщения в очередь, а сервисы (синхронные вызовы) – на ожидание, обновить необходимые модули и запустить приложение с момента приостановки. При этом данные, с которыми работало приложение, никуда не пропадут. Описанный способ обновления кода подойдет в первую очередь тем, кто по каким-то причинам не использует кластеризацию, не хочет дублировать приложения и желает сэкономить ресурсы на конфигурацию и тестирование. Хорошим примером является разработка системы биллинга для компании Axia.

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

Источник

Что происходит, когда вы обновляете свой DNS

Fenix by Takeda11

Многие путаются в обновлении записей DNS, когда изменяют IP-адрес своего сайта. Почему эти записи медленно обновляются? Неужели действительно нужно ждать два дня, чтобы всё обновилось? Почему одни посетители видят новый IP, а другие — старый?

Команда Mail.ru Cloud Solutions перевела статью разработчика и автора статей Джулии Эванс, где она отвечает на эти вопросы и популярно рассказывает, что происходит во время обновления DNS с точки зрения фронтендера.

Вот краткое исследование того, что происходит за кулисами, когда вы обновляете запись DNS.

Как работает DNS: рекурсивные и авторитетные DNS-серверы

Во-первых, нам нужно немного объяснить систему DNS. Существует два вида DNS-серверов: авторитетные и рекурсивные.

Рекурсивные DNS-серверы сами по себе ничего не знают о том, кому принадлежит какой IP-адрес. Они вычисляют IP-адрес для домена, запрашивая его у соответствующих авторитетных DNS-серверов, а затем кэшируют этот IP-адрес на случай, если их снова спросят о нем. Так, 8.8.8.8 — это рекурсивный DNS-сервер.

Когда люди посещают ваш веб-сайт, они, вероятно, делают DNS-запросы к рекурсивному DNS-серверу. Итак, как же работают рекурсивные DNS-серверы? Давайте посмотрим!

Как рекурсивный DNS-сервер запрашивает IP-адрес github.com

Давайте рассмотрим пример того, что делает рекурсивный DNS-сервер (например, 8.8.8.8), когда вы запрашиваете у него IP-адрес (запись А) для github.com. Во-первых, если у него уже есть кэшированный результат, он выдаст его. Но что, если все кэши просрочены? Вот что происходит.

Шаг 1: IP-адреса для корневых DNS-серверов жестко закодированы в его исходном коде. Вы можете увидеть это в исходном коде unbound. Допустим, для начала он выберет 198.41.0.4. Вот официальный источник этих жестко закодированных IP-адресов, также известный как «корневой файл подсказок» (root hints file).

Шаг 2: Спросить корневые серверы имен о github.com.

Детали ответа DNS немного сложнее — в этом случае есть раздел авторитетности (authority section) с некоторыми записями NS и дополнительный раздел с записями A, так что вам не нужно делать дополнительный поиск, чтобы получить IP-адреса этих серверов имен.

У нас есть новый IP-адрес для отправки запроса! Это один из серверов имен для github.com.

Шаг 4: Спросить у серверов имен github.com об адресе github.com.

Мы почти закончили!

Итак, у нас есть запись А для github.com. Теперь у рекурсивного сервера есть IP-адрес github.com, и он может вернуть его вам. И он смог провернуть всю процедуру, начиная всего с нескольких жестко закодированных IP-адресов: адресов корневых серверов имен.

Как увидеть все шаги рекурсивного DNS-сервера: dig +trace

Чтобы посмотреть, что рекурсивный DNS-сервер будет делать для резолвинга домена, можно запустить:

Эта команда показывает все DNS-записи, которые запрашивает рекурсивный сервер, начиная с корневых DNS-серверов, то есть все четыре шага, которые мы только что прошли.

Обновим записи DNS

Теперь, когда мы знаем основы работы DNS, давайте обновим некоторые записи DNS и посмотрим, что произойдет.

При обновлении записей DNS существует два основных варианта:

Поговорим о TTL

Но мы забыли кое-что важное. Это TTL. Как мы сказали ранее, рекурсивный DNS-сервер будет кэшировать записи до истечения срока их действия. Он принимает решение об истечении срока действия записи в зависимости от ее TTL (time to live, времени жизни).

В этом примере сервер имен GitHub для его DNS-записи возвращает TTL 60, что означает 60 секунд:

Это довольно короткий TTL. Теоретически, если бы все DNS-реализации следовали стандарту DNS, это означало бы, что если GitHub решил изменить IP-адрес для github.com, каждый получил бы новый IP-адрес в течение 60 секунд. Давайте посмотрим, как это происходит на практике.

Вариант 1: обновление записи DNS на тех же серверах имен

Во-первых, я обновила свои серверы имен (Cloudflare), чтобы получить новую запись DNS — запись A, которая сопоставляет test.jvns.ca на 1.2.3.4:

Итак, а если мы попытаемся изменить этот IP-адрес? Я изменила его на 5.6.7.8, а затем запустила тот же DNS-запрос:

Похоже, что на этом DNS-сервере запись 1.2.3.4 всё еще кэшируется в течение 144 секунд. Интересно, что если запросить 8.8.8.8 несколько раз, вы получите противоречивые результаты — иногда он выдает новый IP, а иногда старый. Вероятно, 8.8.8.8 на самом деле распределяет нагрузку на кучу разных бэкендов, у каждого из которых собственный кэш.

После пяти минут ожидания все кэши 8.8.8.8 обновились и всегда возвращали новую запись 5.6.7.8. Потрясающе. Это довольно быстро!

Не всегда можно полагаться на TTL

На практике при обновлении записи DNS с пятиминутным TTL можно ожидать, что большой процент клиентов быстро перейдет на новые IP-адреса (например в течение 15 минут), а затем появится куча отставших, которые будут медленно обновляться в течение следующих нескольких дней.

Вариант 2: обновление ваших серверов имен

Итак, мы видели, что когда вы обновляете IP-адрес, не меняя свои серверы имен, многие DNS-серверы довольно быстро получают новый IP-адрес. Отлично. Но что произойдет, если вы измените свои серверы имен? Давайте попробуем!

Я не хотела обновлять серверы имен для своего блога, поэтому вместо этого взяла другой свой домен и использовала его в примерах для журнала по HTTP это examplecat.com.

Когда я внесла изменения, мой доменный регистратор несколько зловеще высветил сообщение: «Изменения в examplecat.com сохранены. Они вступят в силу в течение ближайших 48 часов». Затем я установила новую запись A для домена, чтобы она указывала на 1.2.3.4.

Ладно, давайте посмотрим, изменилось ли что-нибудь:

Никаких изменений. Если я спрошу другой DNS-сервер, то он знает новый IP:

Но 8.8.8.8 по-прежнему ничего не знает. Причина, по которой 1.1.1.1 видит новый IP, хотя я только что изменила его пять минут назад, вероятно, заключается в том, что никто никогда не спрашивал 1.1.1.1 об этом examplecat.com раньше — значит, у него в кэше ничего не было.

У серверов имен TTL намного больше

Причина, по которой мой регистратор говорил: «Это займёт 48 часов» в том, что TTL на NS-записях (сведения о том, к какому серверу имен должен обратиться рекурсивный сервер) намного больше.

Новый сервер имен определенно возвращает новый IP-адрес для examplecat.com:

Но вспомните, что произошло, когда мы запросили серверы имен github.com раньше:

172 800 секунд — это 48 часов! Таким образом, обновление сервера имен, как правило, занимает гораздо больше времени. Время нужно, чтобы закончился срок действия кэшей и распространился новый адрес. Это гораздо дольше, чем просто обновление IP-адреса без изменения вашего сервера имен.

Как обновляются ваши серверы имен

Библиотека DNS-резолвера вашей программы также может кэшировать записи DNS

Еще одна причина, по которой TTL может не соблюдаться на практике: многие программы должны резолвить DNS-имена, а некоторые программы также будут кэшировать DNS-записи в памяти на неопределенный срок (до тех пор, пока программу не перезапустят).

Например, есть статья о настройке JVM TTL для поиска DNS-имен. Я сама писала не так много кода JVM для поиска DNS, но небольшой поиск в интернете о JVM и DNS создает впечатление, что вы можете настроить JVM так, чтобы он кэшировал каждый поиск DNS в течение бесконечного времени (например, см. этот тикет ElasticSearch).

Вот и всё!

Надеюсь, что это поможет вам понять, что происходит при обновлении вашего DNS.

Оговорюсь, что всю историю распространения DNS определяют не только TTL. Некоторые рекурсивные DNS-серверы наверняка не уважают TTL, даже такие основные серверы как 8.8.8.8. Так что даже если вы просто обновляете запись A, указав маленький TTL, возможно, что на практике всё равно будут приходить запросы на старый IP в течение дня или двух.

Источник

Обновление сервера управления — обновление распределенной группы управления

Поддержка этой версии Operations Manager прекращена. Рекомендуем перейти на Operations Manager 2019.

При обновлении распределенной группы управления первым этапом является обновление всех серверов управления в группе управления. При этом имеется ряд обязательных к выполнению предварительных задач. Дополнительные сведения см. в статье Задачи, выполняемые перед обновлением до System Center Operations Manager.

В промежутке между обновлением серверов управления и агентов в журналах управляемых агентом серверов могут появляться записи о событиях, относящихся к мониторингу производительности приложений (APM). Эти записи могут появляться в управляемых агентом серверах, на которых не включена служба APM. Разрешение этих записей журнала событий произойдет, как только вы завершите обновление агентов. Для очистки событий после обновления агентов может потребоваться перезапустить службу мониторинга работоспособности.

Так как сервер сборщика ACS должен быть размещен на том же компьютере, что и сервер управления, рекомендуется выполнить шаги, описанные в разделе Обновление сборщика ACS вместе с обновлением сервера управления, на котором размещаются службы ACS.

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

При обновлении нескольких серверов управления в распределенной группе управления планируйте обновления в такой последовательности, которая наилучшим образом соответствует вашим деловым потребностям. После обновления исходного сервера управления обновите все серверы управления в распределенной группе управления как можно скорее, чтобы убедиться в работоспособности своей обновленной среды.

Обновление сервера управления

Войдите на сервер управления Operations Manager с помощью учетной записи, которая является членом роли «Администраторы» Operations Manager для вашей группы управления Operations Manager, членом предопределенной роли сервера «Системный администратор» SQL Server, а также локальным администратором на этом компьютере.

На носителе Operations Manager запустите программу Setup.exe, а затем нажмите кнопку Установить. Страница Приступая к работе отображает сведения по обновляемым компонентам.

На странице Приступая к работе нажмите кнопку Далее, чтобы продолжить обновление.

На странице Приступая к работе, Прочтите условия лицензионного соглашения изучите условия лицензионного соглашения на использование программного обеспечения корпорации Майкрософт, выберите пункт Условия лицензии прочитаны и понятны. Я принимаю эти условияи нажмите кнопку Далее.

На странице «Приступая к работе», «Выберите расположение установки» оставьте значение по умолчанию, введите новое расположение или выберите нужное. Затем нажмите кнопку Далее.

Путь установки по умолчанию для System Center 2016 — Operations Manager — C:\Program Files\Microsoft System Center 2016\Operations Manager. Путь установки по умолчанию для всех более поздних выпусков (1801, 1807 и 2019) — C:\Program Files\Microsoft System Center\Operations Manager.

На странице «Настройка», «Настройка учетных записей Operations Manager» введите учетные данные из учетной записи домена для учетной записи службы конфигурации и доступа к данным System Center, после чего нажмите кнопку Далее.

Просмотрите страницу Настройка, Все готово к обновлению и нажмите кнопку Обновить. Начинается обновление и отображается ход процесса обновления.

Обновление сервера управления является лишь одним этапом процесса распределенного обновления. Обновление не будет завершено, пока не обновлены все остальные компоненты группы управления. Следующим шагом является обновление всех шлюзов. Дополнительные сведения см. в статье Обновление сервера шлюза.

Обновление сервера управления из командной строки

Войдите на сервер управления с помощью учетной записи, которая является членом роли «Администраторы» Operations Manager для вашей группы управления Operations Manager, членом предопределенной роли сервера «Системный администратор» SQL Server, а также локальным администратором на этом компьютере.

Измените путь, указав путь к файлу Setup.exe для Operations Manager, после чего выполните следующую команду.

После обновления всех серверов управления в группе управления следует обновить серверы шлюзов, после чего обновить все изолированные консоли управления.

Дальнейшие действия

Сведения о задачах после обновления, которые необходимо выполнить для завершения обновления в группе управления, см. в статье Задачи, выполняемые после обновления до версии System Center Operations Manager.

В разделе Распределенное развертывание Operations Manager приводятся сведения о последовательности и процедурах установки ролей сервера Operations Manager на нескольких серверах в группе управления.

Источник