Архивы infrastructure

Разновидности RAM на современных серверах Dell

Вроде бы банальная тема использования планок оперативной памяти на современных серверах на самом деле является не такой уж и простой. Разбирался с этим вопросом недавно для себя на примере серверов Dell. Оказалось, что за последние годы, технологии очень сильно шагнули в этом направлении, и при выборе нового серверного оборудования желательно нужно учитывать различные типы ОЗУ или RAM, которые могут быть использованы в эксплуатации. Думаю, что другие вендоры серверного оборудования используют аналогичные решения. Однако, в контексте данного материала, хотелось бы сконцентрироваться на конкретных серверах Dell PowerEdge. На примере этого оборудования показать тот выбор разнообразия оперативной памяти, который имеется на данный момент у инженеров и системных администраторов.

На текущий момент основные виды оперативки выпускают в виде планок DIMM (Dual Inline Memory Module). Такая динамическая память наиболее распространена в виде UDIMM, RDIMM, и LRDIMM. Кроме этого в продаже появились NVDIMM и DCPMM, которые позволяют обеспечить сохранность информации при выключении сервера. Давайте попытаемся разобраться, что каждый из этих видов ОЗУ представляет из себя и когда лучше их использовать.

Типы портов в SAN FC сети

У сетей SAN или Storage Area Network есть несколько специфических особенностей, которые отличают их от привычных IP сетей. Одна из них наличие разного типа портов в сети SAN. С точки зрения физики и внешнего вида они все абсолютно одинаковые. Однако, с позиции логики работы они могут сильно отличаться. Эта особенность Fibre Channel часто смущает администраторов сетей передачи данных, кому приходится сталкиваться с SAN, в частности, и меня самого. Небольшая статья, которая поможет разложить по полочкам данный вопрос, давно зрела в тайниках моего подсознания, что и стало мотиватором для ее написания. Далее по тексту постараюсь разложить основные нюансы в терминологии сетей FC SAN, что поможет при их проектировании и внедрении.

Подсчет IOPS на RAID массиве

При добавлении нового дискового пространства крайне важно понимать сколько Вам нужно операций чтения/записи или по научному IOPS, а также сколько та или иная дисковая система может Вам выдать таких транзакций в секунду. Такой подсчет в целом не представляет никаких сложностей и доступен любому, кто в ладах со школьной алгеброй. Если с определением объема дискового пространства на RAID массиве, как правило, проблем не возникает, то с подсчетом необходимых, а также доступных IOPS зачастую во многих организациях все обстоит не так гладко. В современных системах хранения данных зачастую используется определенный уровень кеша, технологии tiering, дедупликации и прочие фишки, которые могут влиять на общее значение IOPS. Однако, понимание того, сколько реально операций чтения/записи можно получить от самой дисковой подсистемы дает знание базовой производительности системы, от которого можно отталкиваться при проведении дополнительных расчетов.

Тестирование дисковой системы в Linux

Основные аппаратные ресурсы любого серверного оборудования — это процессор, ОЗУ и дисковая подсистема. Определение их производительности и мониторинг — одни из ключевых задач в эксплуатации такой техники. Тут хотелось бы остановиться на вопросе определения производительности дисковой подсистемы. При этом под таковой я подразумеваю не только один обычный жесткий диск, но и различные сложные системы для хранения данных, которые используются в серверных системах. Современные программно определяемые стораджи настолько далеко ушли в технологиях, что нет смысла в данном контектсе останавливаться на специфике их работы. Давайте рассмотрим ситуацию, когда у нас есть виртуальная или физическая машина с ОС Linux, на которой доступен физический или логический жесткий диск, производительность которого хотелось бы протестировать. Для этих целей идеально подходит небольшая утилита fio. Она очень гибкая и богатая по фунционалу. Позволяет провести разнообразные тесты ввода-вывода дисковых подсистем.

Кеш на SSD в CEPH

Система хранения CEPH уже давно поддерживает функционал кеширования HDD пулов с помощью дисков SSD или NVMe. То есть, сами данные хранятся на массивах медленных HDD дисках, но при этом при оперативной записи/чтении могут использоваться намного более быстрые диски SSD/NVMe. Такой функционал считается одним из базовых в дорогих коммерческих стораджах middle-range уровня. В свое время долгое время занимался такого типа оборудованием. По своему опыту могу сказать, что такое кеширование является одним из важных моментов при выборе СХД в организации. Для Open Source продукта Ceph это важная фича, которая позволяет обеспечить нужную производительность общей системы при использовании шпиндельных дисков при необходимости.

Организуем backup в Proxmox

Один из важнейших компонентов любой системы виртуализации при использовании в продуктовых средах — наличие средств резервного копирования и восстановления. Можно вспомнить о различных вариантах бекапов виртуальных машин VMware, которые были доступны в разное время. И сама компания VMware пыталась реализовать такие решения и сторонние поставщики. В итоге на текущий момент решение VEEAM Backup & Replication стало настолько популярным, что вытеснело по сути все остальные продукты. К большому сожалению, оно поддерживает только среды виртуализации VMware и Hyper-V. Для кластера Proxmox средства по резервному копированию были встроены в сам дистрибутив, однако обладали довольно базовым функционалом. Относительно недавно компанией разработчиком был выпущен Proxmox Backup Server. Данное решение позволяет профессионально бекапить данные как на диски, так и на ленту. Кроме этого этот продукт дает возможность использовать дедупликацию, разнообразные политики резервного копирования и способы работы с виртуальными машинами.

Про систему виртуализации Proxmox уже было несколько статей на моем блоге. Это «Небольшие лайфхаки с Proxmox», «Импорт kvm виртуалок в Proxmox», а также «Миграция виртуальных машин из VMware в Proxmox». Open Source проект Proxmox VE по созданию виртуализированной среды развивается довольно таки успешно. Большим плюсом с моей точки зрения является наличие серьезного объема документации, а также форума, где разбирается огромное количество проблем и различных практических ситуаций. Со своей стороны, публикуя здесь очередную статью о системе виртуализации Proxmox, надеюсь внести посильный вклад в русскоязычное комьюнити пользователей данного замечательного продукта.

FreeIPA клиент на Ubuntu 20.04

Обычная аутентификация на современных системах под управлением ОС Linux, как правило, подразумевает использование файлов /etc/passwd и /etc/shadow, в которых содержится информация о пользователях и их паролях. Однако, недра операционной системы Linux поддерживают с помощью механизма PAM гораздо больше возможностей по аутентификации и авторизации пользователей. PAM (Pluggable Authentication Modules) — низкоуровневые библиотеки, работающие на уровне операционной системы, позволяющие задействовать различные способы идентификации пользователей. Сценарии использования модулей PAM в операционной системе Ubuntu 20.04 находятся в директории — /etc/pam.d/. Другим важным компонентом операционной системы, задействованным в вопросах аутентификации является Name Service Switch. С помощью данного сервиса ОС в том числе определяет источник данных для пользователей и их паролей. Конфигурация данной службы находится в файле — /etc/nsswitch.conf.

FreeIPA клиент в Linux позволяет интегрировать отдельные операционные системы серверов и виртуальных машин в общую управляемую среду с централизованной базой пользователей и правил безопасности. Центральной частью всей подобной системы, безусловно, является сервер FreeIPA, который требует отдельной установки и настройки. Непосредственно на клиентских операционных системах кроме самого freeIPA клиента необходим также System Security Services Daemon (SSSD), который напрямую интегрируется с модулями PAM. При этом сервис SSSD может задействовать различные способы идентификации и аутентификации пользователей — такие как LDAP, Kerberos. Конфигурация демона SSSD находится в файле /etc/sssd/sssd.conf.

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

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

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

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

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

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

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