Архивы Linux - Страница 2 из 3

Создание виртуалок в kvm из консоли

Система виртуализации kvm, созданная и работающая на хостах Linux, с точки зрения управления сильно отличается от привычной для многих VMware vSphere. При работе с ней очень многие вещи приходится делать в консоли, особенно если это продуктовые сервера. Так и установка с нуля гостевых машин с нужной операционной системой требует определенных знаний и смекалки. При этом для виртуальных машин с разными типами ОС на них нужно знать свои нюансы, чтобы получить желаемый результат. Даже разные дистрибутивы Linux требуют дифиринцированный подход. Как запилить себе одну виртуалочку с CentOS Linux 7.9 и еще одну с Ubuntu Linux 20.04 на kvm хочется показать на реальных примерах.

Ранее у себя в блоге писал уже о системе виртуализации на базе kvm — Proxmox-VE. Это были статьи — «Импорт kvm виртуалок в Proxmox» и «Небольшие лайфхаки с Proxmox«. Да, Proxmox обладает отличным графическим веб интерфейсом, имея kvm под капотом. Но зачастую kvm применяется напрямую без лишней обвязки и требует знаний по работе с ним из командой строки Linux с использованием различных утилит управления и мониторинга. С учетом того, что актуальность использования kvm в современном IT мире довольно высокая, знание специфики работы с ним будет далеко не бесполезным для администраторов и программистов.

Небольшие лайфхаки с Proxmox

Система виртуализации Proxmox, работающая на базе гипервизора KVM — неплохое Open Source решение, которое позваляет создавать кластеры, аналогичные VMware. Установка и использование данного продукта в целом не вызывает лишних сложностей и отличается последовательностью и логичностью. Однако, в процессе эксплуатации, нужно быть готовым к небольшим доработкам и донастройкам самой системы виртуализации. Небольшие лайфхаки, которые приходилось использовать в практике, хотелось бы опубликовать в этой статье. Они позволят избежать очевидных небольших «недоработок» в системе при ее использовании с чистого листа. Информация изложенная в статье актуальна для версии Proxmox-VE 6.2.

Разносим данные по hdd и ssd в CEPH

Кластер CEPH по умолчанию представляет собой один общий массив хранения данных, в котором объекты распределяются по всем имеющимся дискам в соответствии с их весом. Но зачастую этого бывает недостаточно. SSD диски уже давно не являются экзотикой, и используются на большинстве серверов, да и обычных десктопах и ноутбуках. Как распределить данные на кластере CEPH таким образом, чтобы SSD диски использовались строго для определенных категорий данных, а HDD для других категорий? Об этом хочется рассказать в этой статье. О CEPH уже писал в своем блоге — Установка кластера CEPH. Однако, тематика данной программно-определяемой системы хранения данных мне кажется благодатной, да и в русскоязычном сегменте Интернета полезных статей о ней не так много.

Установка кластера CEPH

По-настоящему серьезное Open Source решение, которое позволяет организовать отказоустойчивое хранение данных в организации, это CEPH. При этом оно совмещает в себе возможности объектного, блочного и файлового хранения данных. Если аналогичные по функционалу коммерческие продукты стоят колоссальных денег и требуют постоянной покупки сервисов по технической поддержке и гарантии, то CEPH может работать на обычных i386 серверах с использованием недорогого сетевого оборудования. Да, конечно же, чтобы использовать это решение в штате компании должны быть квалифицированные специалисты, понимающие как оно работает и умеющие его настраивать. Как правило, такие специалисты немногочисленны на рынке труда и стоят хороших денег. Однако, и специалисты по серьезным коммерческим системам хранения данных «редкие и дорогие птицы».

Эволюция данной программно-определяемой системы хранения данных показывает неплохие темпы и результаты. Последняя версия данного ПО на текущий момент под названием Octopus хорошо подтянула веб интерфейс. Теперь через графическую панель можно выполнять большое количество задач, оговорюсь сразу, что далеко не все. Раньше веб интерфейс CEPH предоставлял гораздо меньше возможностей и практически все операции проводились через командную строку. Также в последней версии добавилась возможность инсталляции кластера с помощью утилиты cephadm, устанавливаемой на первую ноду создаваемой системы хранения. При этом сам основной функционал хранилища данных в программном продукте CEPH уже давно хорошо себя зарекомендовал.

Информация о дисках в системе Linux

Периодически любому, кто соприкасается профессионально с аппаратным обеспечением IT систем, приходится сталкиваться с вопросами оценки работоспособности жестких дисков. В свое время плотно занимался системами хранения данных EMC. И опыт эксплуатации даже этих самых продвинутых стораджей корпоративного уровня показывает, что после трех — пяти лет их использования, жесткие диски начинают выходить из строя с неотвратимой регулярностью. Эти компоненты серверов, СХД или даже обычных компьютеров с моей точки зрения представляют собой расходный материал, которые нужно быть готовым менять постоянно в долгосрочной перспективе. Если использование корпоративных стораджей по своей философии предполагает постоянную покупку сервисов технической поддержки, и соответственно замену дисков вендором в случае проблем с ними. То в случае использования серверных решений на базе стандартных операционных систем Linux или Windows, вопросом обслуживания жестких дисков нам придется заниматься полностью самим.

Все современные нормальные жесткие диски и диски SSD имеют на борту систему мониторинга S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology или SMART). Если такой поддержки на имеющихся у Вас дисках нет, то стоит задумать сразу же о целесообразности их использования. Система SMART встроена в микросхемы контроллера диска и содержит в себе информацию о показателях жизнедеятельности данного драйва. Что хорошо, так это то, что из операционной системы сервера или компьютера, где установлены диски, можно легко получить доступ к данным этой системы. Это позволяет администратору быть постоянно в курсе состояния используемых драйвов. Также с помощью имеющейся информации можно проводить заблаговременно замену дисков, там где находятся критически важные данные.

Отказоустойчивость доступа к сети в Linux

Те, кто занимается сетевыми технологиями, наверняка знает множество различных способов обеспечения отказоустойчивости компьютерных сетей. При этом есть как общеиспользуемые стандартизированные решения на L2 или L3 уровнях, так и узкие специализированные наработки. Сервера Linux также обладают всем необходимым функционалом, чтобы обеспечить выживаемость сервера в случае выхода из строя сетевой карты или отдельного коммутатора. Для этого используется функционал бондинга (bonding), который позволяет объединять в один общий виртуальный линк несколько физических интерфейсов. Данная возможность присутствует в различных дистрибутивах операционной системы Linux и может отличаться небольшой спецификой в настройке. Разные дистрибутивы используют свои конкретные механизмы настройки сети. Однако, непосредственные технические возможности по обеспечению сетевой отказоустойчивости остаются идентичными.

С помощью бондинга мы можем объединять несколько Ethernet интерфейсов в один виртуальный линк. При этом с противоположной стороны могут находиться как несколько различных коммутаторов, так и одно сетевое устройство. Так в случае использования протокола LACP мы можем объединить и одновременно использовать неисколько интерфейсов одновременно. Это позволяет обеспечить не только отказоустойчивость, но и повысить скорость доступа к сети в случае такой необходимости. Но для этого мы должны подключать все интерфейсы в один коммутатор, который поддерживает протокол LACP. Если же мы подключаем сетевые интерфейсы к различным коммутаторам, то можем использовать режим бондинга active-backup, который использует только один активный линк в данное конкретное время, но позволяет переключаться на резервные в случае выхода из строя основного.

Отправка email с серверов

На вопрос нужно или нет отправлять почту с работающих серверов — для меня ответ всегда был положительным. Здесь конечно же идет речь не об отправке различного рода спама в Интернете, а об использовании электронных писем с различными оповещениями из IT систем на серверах. С помощью электронной почты всегда можно было доставлять нужные сообщения администраторам и программистам, уведомляя их о тех или иных событиях в работе IT систем. Да, сейчас есть ряд альтернативных способов доставки сообщений о происшествиях в программном обеспечении и оборудовании. Это, например, SMS или мессенджер Telegram. Такие способы, как правило, используются в системах мониторинга, позволяя оперативно сообщать о критических инцидентах. Однако, с моей точки зрения, использование электронной почты актуально и полезно и сегодня. Функции сортировки электронных писем позволяют эффективно анализировать тренды и выявлять проблемы в работе IT систем.

Для того, чтобы наш сервер стал способным отправлять почтовые сообщения, мы должны установить и настроить на нем MTA агент. MTA — Mail Transfer Agent (Агент передачи электронной почты). Программное обеспечение, выполняющее функцию MTA, занимается пересылкой электронных писем по протоколу SMTP. На основе него строятся серьезные почтовые сервера, которые способны обслуживать тысячи и миллионы пользователей. Нам в общем случае такой функционал избыточен. Наиболее популярные MTA в операционной системе Linux — Postfix, Sendmail, Qmail, Exim. Я предпочитаю работать с Linux системами на серверах, поэтому затрагивать тему использования MTA на платформах Windows не буду. Мне хотелось бы показать как быстро установить и настроить пакет Exim4, для целей доставки почтовых уведомлений с конкретного сервера. Его компактность, надежность и наличие всего необходимого просто идеально подходят для этой цели.

Netstat и аналоги

У каждого администратора, IT инженера или программиста наверняка есть несколько десятков базовых утилит или команд, которые постоянно применяются в работе. У меня также есть такой набор базовых инструментов, который является неотъемлемой частью моей профессии. Среди них можно назвать wget, curl, ping, vim, tree, git, ip ну и конечно же netstat. Последняя являлась незаменимой утилитой при работе на абсолютно разных платформах, начиная от всевозможных версий Linux, Unix, BSD и заканчивая MacOS, а так же Microsoft Windows. С помощью нее можно получать информацию о сетевых соединениях, интерфейсах, таблицах маршрутизации. Утилитка позволяет получать обширнейшую информацию, которая бывает полезна во время траублшутинга, дебагинга или настройки чего-то нового.

В последние несколько лет отчетливо прослеживается тенденция на замену утилиты netstat на более новые ее аналоги — ss и lsof. Так уже в Centos по умолчанию Вы не найдете netstat, Вам предлагается использовать уже именно ss, а также lsof. Можно конечно же устанавливать netstat из пакетов и не париться о новых его аналогах. Мне однако такой путь кажется не правильным. Время идет, технологии развиваются, и надо обязательно изучать новинки, даже если они на первый взгляд кажутся бесполезными. При написании этой статьи не ставил цели сделать какое-то наглядное пособие по использованию новых аналогов netstat. Хотел скорее показать, как безболезненно перейти на новые утилиты, расширив свой профессиональный кругозор и функциональные возможности.

Docker-сompose на практике

Чем больше Вы работаете с Docker, тем чаще испытываете необходимость запускать одновременно сразу несколько контейнеров в связке. Это позволяет обеспечить работоспособность приложений, требующих нескольких компонентов для своего функционирования. Банальный пример, который иллюстрирует часто встречающую связку из реальной жизни — nginx, php-fpm и mysql. Как правило, современные веб приложения в минимальной конфигурации требуют СУБД — mysql, поддержку PHP, и возможность отдачи через веб сервер. Данную связку легко поднять с помощью 3 контейнеров, каждый из которых будет выполнять свой процесс. Так контейнер с nginx будет взаимодействовать с пользователями, контейнер с php-fpm обрабатываь PHP скрипты, а контейнер с mysql хранить информацию. Сами скрипты PHP и вспомогательные файлы приложения могут спокойно храниться на сервере, где работает Docker. С помощью Docker-compose проблема работы такой связки решается легко и эффективно.

Docker-compose позволяет сгруппировать вместе несколько контейнеров и использовать их в работе как единую группу. Вам не придется в процессе их работы думать о том, как они между собой связаны и что нужно сделать, чтобы эту взаимосвязь поддержать. При этом сам принцип работы предельно простой и требует по большому счету только понимание написания yaml файлов. Вся конфигурация группы контейнеров создается в одном общем файле, который определяет зависимости и принцип работы этой группы. При этом подразумевается, что у Вас есть понимание принципов работы Docker и Вы уже умеет создавать Dockerfile для своих контейнеров.

Защита веб приложений с nginx

Частенько в процессе работы в IT возникает задача организовать защищенное быстрое функционирование того или иного веб приложения. У кого-то используются свои самописные приложения. У кого-то это сторонние готовые приложения. Но при этом приложения могут работать без аутентификации, либо при запуске использовать большой объем ОЗУ. Это, как правило, приложения на JAVA, Python и т.д., которые запускаются напрямую без использования веб сервера. В принципе, они конечно могут работать и таким образом. Но, в реальных продакшн условиях, это неэффективно с точки зрения компьютерных ресурсов. А также не секьюрно с точки зрения информационной безопасности. Во всех подобных случаях настоятельно советую использовать Nginx веб сервер как реверс прокси для Вашего приложения.

Основные преимущества такой конфигурации просты и очевидны. Во-первых, основная нагрузка по взаимодействию с клиентами перкладывается на профессиональный веб сервер. Nginx с этим делом справляется просто на УРА с минимальными затратами процессора и памяти. Во-вторых, возможность с легкостью устанавливать пароль для доступа к данному приложению. В организационной рабочей среде, приложение без пароля просто находка для хакера. Ну и в-третьих, быстрая настройка доступа через HTTPS протокол, что обеспечивает безопасность передачи данных по сети. Если у Вас публичный сервис, то Вы также можете настроить сертификат с помощью LetsEncrypt, о чем ранее писал в статье на этом блоге. Если сервис непубличный, то придется использовать свои самоподписанные сертификаты.