Серверное администрирование *

Привет, меня зовут Сергей Качеев, я старший разработчик в отделе сетевой инфраструктуры Яндекса. Сегодня я расскажу целый сетевой детектив о том, как мы искали баг, который убивал DNS сервер Unbound. Приготовьтесь, он будет долгим.

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

В самом начале на графиках нагрузочного тестирования я увидел очень плохие результаты: случайным образом абсолютно все запросы нагрузочного теста таймаутились, но сервер, который был под нагрузкой, никак не реагировал на проблему. Как выяснилось позже, по чистой случайности я допустил ошибку в конфигурации нашего плагина Pandora, и в итоге он сам ходил в DNS на каждый запрос, чтобы узнать ip адрес тестируемого сервера. Возможно, это сыграло мне на руку и помогло найти первую из проблем, а потом и вовсе задало вектор поисков остальных багов. А в Unbound их накопилось достаточно.

Продолжаем серию видео о возможностях нашей платформы. В этот раз показываем, как работает резервное копирование. 

Уникальность поддержки систем резервного копирования (СРК) со стороны vStack — в отсутствии привязки к какой-то одной СРК. Мы выбрали подход, не принуждающий потребителей с существующей экосистемой бэкапа к переходу на другую СРК и миграции архивных копий в формат новой СРК. 

Это стало возможно благодаря поддержке протокола NDMP со стороны vStack. Он давно реализован во всех СРК корпоративного уровня, например, IBM Spectrum protect (ранее называвшийся Tivoli Storage Manager) и NetVault Backup. Его работа выверена годами использования как в СРК, так и в СХД, где он также активно используется для резервного копирования. Кроме того, поддержка протокола NDMP существует и в системах с открытым исходным кодом, например, BareOS. Это может быть важно для тех, кто рассматривает открытые решения.

Мы записали видео с демонстрацией работы бэкапа виртуальной машины vStack. В качестве СРК используется EMC NetWorker, имеющая каноническую реализацию протокола NDMP в силу того, что EMC — один из двух оригинальных разработчиков этого протокола.

Одна из самых популярных и при этом не всегда логирующаяся ошибка apache2 - «Internal Server Error». Много времени было мной потрачено на поиски решения, когда с ней сталкивался. Процесс решения и причины возникновения описанны здесь.

Друзья, ваши комментарии к нашему предыдущему материалу натолкнули нас на мысль рассказать об отказоустойчивости платформы vStack подробнее. Мы и сами любим интересные дискуссионные темы, поэтому готовим AMA (ask me anything)-сессию, на которой ответим на все ваши вопросы. А пока выбираем удобное время, руководитель проекта vStack Евгений Гаврилов записал пару коротких видео с наглядной демонстрацией отказоустойчивости платформы. 

С ростом онлайн-магазина возникла необходимость выбрать недорогой, но при этом надёжный VPS-сервер. Начитался на Хабре инструкций по выбору и решил сравнить несколько вариантов по услугам, ценам, отзывам/репутации. 

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

Любая распределенная система, например включающая несколько микросервисов со своими источниками данных (и особенно запущенная внутри сложной системы оркестрации, которая сама по сути является распределенным приложением), обладает множеством точек отказа и по мере ее масштабирования и развития становится все сложнее обнаружить проблемы в функционировании (например, долгий ответ одного из микросервисов), которые приводят к общей потере производительности и даже отказам при высокой нагрузке (или при других неудачных стечениях обстоятельств). И даже если обнаружить сам факт наличия проблемы еще возможно через метрики систем мониторинга, наиболее часто для этого используются замеры задержки ответа, интенсивности запросов, операционные метрики насыщенности сервиса (например, отношение одновременно обрабатываемых запросов к лимиту или замеры процессорного время и/или зарезервированной памяти), то выяснить истинную причину возникновения отклонения уже не так просто (например, это может быть неудачная настройка кэшей запросов базы данных или достижения лимита подключений из‑за того, что приложение не использует пул и т. д.). Чтобы решить эту задачу используются сочетания инструментов (мониторинг, отслеживание распределенных операций и логирование), которые объединяются в общем подходе Observability. В этой статье мы рассмотрим несколько стеков и инструментов для наблюдения за приложениями в Kubernetes.

На прошлой неделе мы представили 3CX v18 Update 7. Ключевые технологии в этом обновлении  - автоматическая настройка DECT-баз, групповое развертывание IP-телефонов, расширенная поддержка VoIP-провайдеров и установка 3CX из облачных маркетплейсов. Расскажем о каждой новинке подробнее.

Программистов, сисадминов, devops'ов, тестировщиков часто объединяет использование некоторых общих технологий. Например, возможность иметь удалённый доступ к серверу пригодилось бы любому из указанной выше анекдотичной компании. Поэтому в этой статье мы рассмотрим основы работы с протоколом SSH на базовом уровня (без генерации ключей, подписей, мам, пап и кредитов). "Продвинутое" использование посмотрим уже отдельно, в следующий раз. Материал подготовил Макс, автор YouTube-канала PyLounge. Поехали!

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

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

Как проверить стабильность работы сервера Proxmox Backup и избежать потери времени.

Разработчики PBS стремились создать интуитивно понятное решение, удобное для пользователя и с простым интерфейсом, и им это вполне удалось. Однако наша практика показала, что новым пользователям Proxmox не хватает наглядной и простой инструкции для работы с этой системой виртуализации. И мы решили исправить эту ситуацию. 

Мне часто приходится пользоваться PowerShell. Конечно, его создатели не имели никакого представления о прекрасном и эстетике. Уродливость PowerShell особенна видна при его сравнении, например, с Python. С другой стороны, как говорится, c лица не воду пить - работает и хорошо? Но нет, мне кажется в PowerShell есть по крайней мере пара моментов, которые фатально влияют на его практическое применение.

Я как потребитель уважаю только честный маркетинг, честные сравнения, честное тестирование различных систем. Зачастую, когда я читаю различные пресс‑релизы от различных вендоров то понимаю, что надо читать сноски‑звездочки и опираться на независимые источники. Наверное, этим грешат все и это печально. В сравнении гипервизоров отчет от Microsoft покажет, что Hyper‑V лучше всех, Vmware скажет, что лучшее решение для виртуализации — ESXi так далее.

Сугубо мое мнение — надо опираться на реально независимые отчеты, такие как Magic Quadrant, это серия отчетов об исследованиях рынка, опубликованных ИТ‑консалтинговой фирмой Gartner, которые основаны на собственных методах анализа качественных данных для демонстрации тенденций рынка, таких как направление, зрелость и участники.

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

В свете этого начал рассматривать отечественные альтернативы Vmware а именно систем виртуализации, и на глаза попалось решение, позиционируемое как альтернатива Vmware. Если в поиске Яндекс забить поисковый запрос, то на первой странице будет довольно интересный материал о продукте vStack (первая маленькая буква v и вторая заглавная как под копирку напоминаем название продуктов VMware, надеюсь это только совпадения а не попытка быть казаться похожим на лидера рынка).