Рубрика «Серверное администрирование» - 53

Kubernetes tips & tricks: о выделении узлов и о нагрузках на веб-приложение - 1

В продолжение наших статей с практическими инструкциями о том, как облегчить жизнь в повседневной работе с Kubernetes, рассказываем о двух историях из мира эксплуатации: выделении отдельных узлов под конкретные задачи и конфигурации php-fpm (или другого сервера приложений) под большие нагрузки. Как и прежде, описанные здесь решения не претендуют на идеал, а предлагаются как отправная точка для ваших конкретных случаев и почва для размышлений. Вопросы и улучшения в комментариях — приветствуются!Читать полностью »

image

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

Команда сборки Docker 18.09 включает множество обновлений. Основная особенность — в том, что появился абсолютно новый вариант реализации серверной части, он предлагается в рамках проекта Moby BuildKit. Серверное приложение BuildKit обзавелось новыми функциями, среди которых — поддержка секретов сборки Docker-файлов.

Читать полностью »

mRemoteNG снова торт - 1 Если вы администратор нескольких десятков Windows и Linux серверов, пачки коммутаторов и маршрутизаторов, то без менеджера удаленных подключений можно быстро и надёжно сойти с ума.

TL;DR. mRemote, разработка которой была давным-давно заброшена, обрела новую жизнь. Если вы пользуетесь RDCMan или Remote Desktop free от Devolutions — попробуйте mRemoteNG!
Читать полностью »

image
В предыдущем посте мы масштабировали набор реплик MongoDB и познакомились со StatefulSet. Сейчас мы займемся оркестрацией кластера высокой доступности Elasticsearch (с другими мастер-нодами, нодами данных и клиентскими нодами) и задействуем ES-HQ и Kibana.

Вам понадобятся:

  1. Базовое представление об Elasticsearch, его типах нод и их ролях.
  2. Работающий кластер Kubernetes как минимум с тремя нодами (не меньше четырех ядер, 4 ГБ).
  3. Умение работать с Kibana.Читать полностью »

Открыта регистрация на Слёрм-3.
Это трехдневный интенсив по Kubernetes для тех, кто ничего не знает о технологии или начал ее осваивать. Фишка интенсива в практике. Каждый участник сам создаст кластер в облаке Selectel, настроит его и развернет в нем приложение.

Открыта регистрация на интенсив по Kubernetes 1-3 февраля в СПб - 1

Слёрм-3 пройдет в Санкт-Петербурге 1–3 февраля 2019.

Зачем нужен Слёрм, если есть мануалы? Он экономит несколько месяцев, которые иначе вы потратили бы на чтение и самостоятельные эксперименты.

Краткая история вопроса.

Первый Слёрм прошел в августе 2018. Это был эксперимент, который удался, несмотря на кучу ошибок и проблем. Отчет.

Читать полностью »

GitHub использует MySQL в качестве основного хранилища данных для всего, что не связано с git, поэтому доступность MySQL имеет ключевое значение для нормальной работы GitHub. Сам сайт, интерфейс API на GitHub, система аутентификации и многие другие функции требуют доступа к базам данных. Мы используем несколько кластеров MySQL для обработки различных служб и задач. Они настроены по классической схеме с одним главным узлом, доступным для записи, и его репликами. Реплики (остальные узлы кластера) асинхронно воспроизводят изменения главного узла и обеспечивают доступ для чтения.

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

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

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

Высокая доступность MySQL в GitHub - 1Читать полностью »

Месяц с небольшим тому назад компания 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 раз отрезать”.

За подробностями добро пожаловать под кат.

Применяем Veeam Backup & Replication для тестирования новых систем и приложений перед апгрейдом - 1
Читать полностью »

Ceph — это object storage, призванный помочь построить отказоустойчивый кластер. И все-таки отказы случаются. Все, кто работает с Ceph, знают легенду о CloudMouse или Росреестре. К сожалению, делиться отрицательным опытом у нас не принято, причины провалов чаще всего замалчивают, и не дают будущим поколениям научиться на чужих ошибках.

Что ж, настроим тестовый, но близкий к реальному кластер и разберем катастрофу по косточкам. Измерим все просадки производительности, найдем утечки памяти, разберем процесс восстановления обслуживания. И все это под руководством Артемия Капитулы, который потратив почти год на изучение подводных камней, заставил при отказе производительность кластера не падать в ноль, и latency не подскакивать до неприличных значений. И получил красный график, который ну сильно лучше.
Ceph. Анатомия катастрофы - 1

Далее вы найдете видео и текстовую версию одного из лучших докладов DevOpsConf Russia 2018.

Читать полностью »

Прим. перев.: Этой статьёй, написанной Scott Rahner — инженером в Dow Jones, мы продолжаем цикл многочисленных материалов, доступно рассказывающих о том, как устроен Kubernetes, как работают, взаимосвязаны и используются его базовые компоненты. На сей раз это практическая заметка с примером кода для создания хука в Kubernetes, демонстрируемого автором «под предлогом» автоматического создания sidecar-контейнеров.

Как этот sidecar-контейнер оказался здесь [в Kubernetes]? - 1
(Автор фото — Gordon A. Maxwell, найдено на просторах интернета.)

Когда я начал изучать sidecar-контейнеры и service mesh'и, мне потребовалось разобраться в том, как работает ключевой механизм — автоматическая вставка sidecar-контейнера. Ведь в случае использования систем вроде Istio или Consul, при деплое контейнера с приложением внезапно в его pod'е появляется и уже настроенный контейнер Envoy (схожая ситуация происходит и у Conduit, о котором мы писали в начале года — прим. перев.). Что? Как? Так начались мои исследования…Читать полностью »

Splunk глазами новичка: как мы делали систему инвентаризации хранилищ - 1

Недавно заказчик попросил нас реализовать систему учета дисковых мощностей. Стояла задача объединить информацию с более семидесяти дисковых массивов разных вендоров, от свичей SAN и ESX-хостов VMware. Затем данные нужно было систематизировать, проанализировать и иметь возможность выводить на дашборд и различные отчеты, например, о свободном и занятом объеме дискового пространства во всех или отдельно взятых массивах.

Мы решили реализовать проект с помощью системы анализа операционной деятельности — Splunk.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js