В предыдущем посте мы масштабировали набор реплик MongoDB и познакомились со StatefulSet. Сейчас мы займемся оркестрацией кластера высокой доступности Elasticsearch (с другими мастер-нодами, нодами данных и клиентскими нодами) и задействуем ES-HQ и Kibana.
Открыта регистрация на Слёрм-3.
Это трехдневный интенсив по Kubernetes для тех, кто ничего не знает о технологии или начал ее осваивать. Фишка интенсива в практике. Каждый участник сам создаст кластер в облаке Selectel, настроит его и развернет в нем приложение.
Слёрм-3 пройдет в Санкт-Петербурге 1–3 февраля 2019.
Зачем нужен Слёрм, если есть мануалы? Он экономит несколько месяцев, которые иначе вы потратили бы на чтение и самостоятельные эксперименты.
Краткая история вопроса.
Первый Слёрм прошел в августе 2018. Это был эксперимент, который удался, несмотря на кучу ошибок и проблем. Отчет.
GitHub использует MySQL в качестве основного хранилища данных для всего, что не связано с git, поэтому доступность MySQL имеет ключевое значение для нормальной работы GitHub. Сам сайт, интерфейс API на GitHub, система аутентификации и многие другие функции требуют доступа к базам данных. Мы используем несколько кластеров MySQL для обработки различных служб и задач. Они настроены по классической схеме с одним главным узлом, доступным для записи, и его репликами. Реплики (остальные узлы кластера) асинхронно воспроизводят изменения главного узла и обеспечивают доступ для чтения.
Доступность главных узлов критически важна. Без главного узла кластер не поддерживает запись, а это значит, что нельзя сохранить необходимые изменения. Фиксация транзакций, регистрация проблем, создание новых пользователей, репозиториев, обзоров и многое другое будет просто невозможно.
Для поддержки записи необходим соответствующий доступный узел – главный узел в кластере. Впрочем, не менее важна возможность определить или обнаружить такой узел.
В случае отказа текущего главного узла важно обеспечить оперативное появление нового сервера ему на замену, а также иметь возможность быстро оповестить об этом изменении все службы. Общее время простоя складывается из времени, уходящего на обнаружение сбоя, отработку отказа и оповещение о новом главном узле.
Месяц с небольшим тому назад компания Microsoft объявила о выходе новейшей версии Windows Server 2019. Однако после GA (general availability) были обнаружены серьезные недостатки, как и в Windows 10 October 2018 Update (оно же 1809) – установка обновления приводила к потере данных (файлы из My Documents жестоко удалялись, так что их нельзя было восстановить из Windows.old). Производитель был вынужден отменить релиз до устранения проблемы. И вот наконец-то 13 ноября починенная версия увидела свет.
Наряду с этим следует вспомнить, что скоро Microsoft завершит поддержку SQL Server 2008 R2 и Windows Server 2008 R2.
Естественно, что у пользователей возникает множество вопросов по переходу на новые системы:
Переезжать ли в облако Microsoft Azure? Как безопасно повысить функциональный уровень домена? Переходить ли на Azure SQL? Может, надо виртуализировать Windows Server 2008 R2 или перенести в Azure? Надо ли мигрировать на новейший Hyper-V?
Миграция на новую платформу нужна, чтобы обеспечить для критически важных приложений, работающих в ЦОД, наличие системы, поддерживаемой вендором. Поэтому важно, чтобы миграция прошла без сюрпризов. Пользователям Veeam повезло — у них есть хорошие способы минимизировать риски при подобных операциях, чтобы, как говорится, “7 раз отмерить, 1 раз отрезать”.
За подробностями добро пожаловать под кат.
Ceph — это object storage, призванный помочь построить отказоустойчивый кластер. И все-таки отказы случаются. Все, кто работает с Ceph, знают легенду о CloudMouse или Росреестре. К сожалению, делиться отрицательным опытом у нас не принято, причины провалов чаще всего замалчивают, и не дают будущим поколениям научиться на чужих ошибках.
Что ж, настроим тестовый, но близкий к реальному кластер и разберем катастрофу по косточкам. Измерим все просадки производительности, найдем утечки памяти, разберем процесс восстановления обслуживания. И все это под руководством Артемия Капитулы, который потратив почти год на изучение подводных камней, заставил при отказе производительность кластера не падать в ноль, и latency не подскакивать до неприличных значений. И получил красный график, который ну сильно лучше.
Далее вы найдете видео и текстовую версию одного из лучших докладов DevOpsConf Russia 2018.
Прим. перев.: Этой статьёй, написанной Scott Rahner — инженером в Dow Jones, мы продолжаем цикл многочисленных материалов, доступно рассказывающих о том, как устроен Kubernetes, как работают, взаимосвязаны и используются его базовые компоненты. На сей раз это практическая заметка с примером кода для создания хука в Kubernetes, демонстрируемого автором «под предлогом» автоматического создания sidecar-контейнеров.
![Как этот sidecar-контейнер оказался здесь [в Kubernetes]? - 1](https://www.pvsm.ru/images/2018/11/29/kak-etot-sidecar-konteiner-okazalsya-zdes-v-Kubernetes.jpeg "Как этот sidecar-контейнер оказался здесь [в Kubernetes]? - 1")
(Автор фото — Gordon A. Maxwell, найдено на просторах интернета.)
Когда я начал изучать sidecar-контейнеры и service mesh'и, мне потребовалось разобраться в том, как работает ключевой механизм — автоматическая вставка sidecar-контейнера. Ведь в случае использования систем вроде Istio или Consul, при деплое контейнера с приложением внезапно в его pod'е появляется и уже настроенный контейнер Envoy (схожая ситуация происходит и у Conduit, о котором мы писали в начале года — прим. перев.). Что? Как? Так начались мои исследования…Читать полностью »
Недавно заказчик попросил нас реализовать систему учета дисковых мощностей. Стояла задача объединить информацию с более семидесяти дисковых массивов разных вендоров, от свичей SAN и ESX-хостов VMware. Затем данные нужно было систематизировать, проанализировать и иметь возможность выводить на дашборд и различные отчеты, например, о свободном и занятом объеме дискового пространства во всех или отдельно взятых массивах.
Мы решили реализовать проект с помощью системы анализа операционной деятельности — Splunk.
Читать полностью »
Как запустить SQL profiler trace, когда проблему надо ловить с 3:00 до 3:30 утра? Делать это можно с помощью трейса на стороне сервера, но это крайне неудобно. Именно не сложно, а неудобно, и всегда лень. Наконец я решился автоматизировать это раз и навсегда. Вот так:
Очередная статья в серии «Инструменты мониторинга Logicify» рассказывает о Grafana. Это программное средство мы используем для визуализации и анализа данных как внутренних, так и внешних проектов. Статья может быть полезна техническим директорам, разработчикам, DevOps, системным администраторам, менеджерам проектов, а также всем заинтересованным лицам.
В начале ноября VMware объявили о покупке стартапа Heptio, создающего корпоративные инструменты для развертывания Kubernetes. Вместе с разработками стартапа в компанию перейдут основатели Heptio, которые ранее создали сам фреймворк Kubernetes.
Разбираемся, на что повлияет эта сделка.
