Александр Руденко @fatruden - Tumblr Blog

Первая статья на хабре :)

Никогда не писал ничего на хабре и вот довелось: https://habr.com/company/croccloudteam/blog/422905/

View On WordPress

Ceph: memory optimization

В этой заметке я расскажу о нескольких параметрах ядра которые очень критичны для нормальной работы Ceph OSD и RGW.

Отключение THP

THP – Transparent Huge Pages. Тут я хотел дать ссылку на описание THP, но к сожалению не смог найти понравившееся мне описание. Напишу пару слов о том, что это такое. Архитектура x86 позволяет оперировать страницами памяти размером в 4Kb, 2Mb, 1Gb где 4Kb –…

View On WordPress

Ceph Object Gateway (radosgw): Object Lifecycle Management

Ceph Luminous очень богатый на фичи релиз и я планирую кратенько написать о всех наиболее интересных на мой взгляд новшествах по части RGW и S3 API работоспособность которых я проверил.

Object Lifecycle Management – это S3 API позволяющий задать политику:

– удаления объектов и/или их версий после заданной даты, – удаления объектов и/или их версий после истечения указанного времени, – перемещения…

View On WordPress

dmesg time to real time

Наверное все видели как выглядят логи в кольцевом буфере ядра. Каждое событие в этом логе имеет timestamp в секундах. Timestump каждого события говорит нам на какой секунде работы системы произошло событие. На самом деле там кроме секунд указываются еще и наносекунды(после точки).

Типичный для меня случай. kdump обработал kernel panic, сдампил содержимое кольцевого буфера(по сути самые актуальные…

View On WordPress

Ceph: Настройка scrub и снижение его влияния на производительность

Обычно не пишу о том, что и так известно почти всем или если это хорошо освещено. Но недавно в одном популярном русскоязычном telegram-чате посвященном Ceph обсуждалась проблема scrubbing’а и я понял, что все таки знаю кое что, что еще не известно всем) Решил написать заметку посвященную данной теме. (more…)

View On WordPress

ceph-mgr: dashboard, zabbix, RESTful, status, balancer

ceph-mgr (Manager daemon) – сервис который стал обязательным с версии Luminous. Кроме того, что он обязательный вместе с ним поставляется несколько модулей которые можно включит и использовать если то, что они дают вам нужно. В этой заметке я пробегусь по списку используемых мной модулей, покажу как их настроить и отмечу некоторые не очевидные моменты из-за которых я решил об этом написать.

Списо…

View On WordPress

Чтобы письма не попадали в spam или о настройке почтовой инфраструктуры.

Я совсем не специалист по почтовым серверам и их настройке, но внезапно встала задача по организации такового для отправки почты от имени нескольких совершенно разных доменов. Речь шла исключительно об отправке(без приема) и задача казалась мне совершенно простой. Как наивен я был… Собственно данная заметка о том как в 2k18-ом нужно заморочиться, что бы письма отправляемые вашим почтовым сервером…

View On WordPress

Про эффективность swap в Linux

Попалась на глазе интересная статья(перевод) про полезность swap в Linux и потенциальных проблемах его отключения: В защиту swap’а [в Linux]: распространенные заблуждения

Эта заметка чисто для себя, с целью фиксации основной мысли автора:

Есть анонимная память(Anonymous Memory) которую можно вытеснить на диск при низкой активности ее использования и высвободить тем самым место для файлового…

View On WordPress

S3 Performance Test Tool

Неплохая утилита для тестирования производительности AWS S3 или S3 совместимого объектного хранилища типа Ceph. Так же ее можно использовать для нагрузочных тестов имитируя различную нагрузку.

Код проекта: https://github.com/jenshadlich/S3-Performance-Test Утилита написана на Java и если вам как и мне не хочется возиться с Java то есть готовый Docker image: https://hub.docker.com/r/javamaster/s3p…

View On WordPress

#Ceph #S3

Ceph Object Gateway (RadosGW): performance monitoring (Zabbix)

Про доступные метрики производительности RadosGW(RGW) я писал отдельную заметку. В этот раз я опишу как мы у себя собираем эти метрики в Zabbix.

Скрипт сбора метрик, user_parameters.conf и собственно шаблон для Zabbix – https://github.com/FATruden/rgw-monitoring (more…)

View On WordPress

#Ceph #rados #Zabbix

Ceph Object Gateway (RadosGW): performance monitoring

RadosGW или RGW он же Ceph Object Gateway позволяет работать с хранилищем RADOS(он же Ceph) через REST API совместимый с S3 и Swift. RGW является прослойкой между пользователем использующим REST и хранилищем RADOS взаимодействие с которым осуществляется по алгоритму CRUSH. У всех компонентов Ceph есть метрики позволяющие мониторить производительность и понимать, что происходит в кластере. У RGW…

View On WordPress

#Ceph #RadosGW #S3

Так вышло, что мое отношение к платформе виртуализации от VMware до этого момента было совсем косвенным. Я регулярно знакомился с возможностями новых версий и следил за развитием технологий используемых VMware. Но в рабочей деятельности, повсеместно применялись продукты Citrix. В частности, для виртуализации серверов использовался XenServer. В случае, если было нужно совсем условно бесплатное решение то, применялся Proxmox VE или настроенный в ручную KVM под управлением CloudStack. Но, момент встречи лицом к лицу с VMware vSphere все же настал. Возникла необходимость произвести развертывание и подготовку к конечной эксплуатации платформ VMware vSphere 5.5 Enterprise, Horison View 5.2 и ряда сопутствующих продуктов - Operation Manager, vCloud Networking and Security. Собственно, в результате довольно тесного знакомства с ними, возникло желание написать статью, посвященную vSphere 5.5. Своего рода обзор новшеств, успешных решений, багов и недоработок. И все это, со стороны опытного админа XenServer. Читать далее >>

#VMware #vsphere #виртуализация

Платформа XenApp состоит из девяти функциональных ролей, три из которых являются базовыми и шесть дополнительных. Базовые роли обеспечивают виртуализацию и доставку приложений конечным пользователям и являются обязательными для развертывания. Дополнительные - расширяют функционал платформы. Их доступность зависит от редакции XenApp. Также существуют ряд опциональных компонентов, которые входят в состав ролей или реализованы отдельными сущностями. Все роли, без исключений, могут быть развернуты на одном сервере или разнесены на отдельные физические или виртуальные сервера. Далее http://ivirt-it.ru/citrix-xenapp-all/

#виртуализация #citrix #XenApp

VMware vSphere позволяет ограничить любого пользователя или группу определенным набором действий. Но, эта система разделения прав доступа предполагает ролевое разделение полномочий. То есть позволяет распределить обязанности между администраторами, но она не как не лимитирует ресурсы затрачиваемые ими. В такой схеме, любой оператор ВМ может на создавать виртуалок, столько сколько ему вздумается, что в моем конкретном случае не приемлемо. Я долго бился над решением этой задачи. Далее http://ivirt-it.ru/vsphere-resource-pool-permissions/

#виртуализация #vsphere #vmware

Архитектура OVS состоит из трех основных компонентов: базы данных, непосредственно программного коммутатора и управляющего контроллера. На каждом из физических узлов, вместе с гипервизором располагаются собственные БД и коммутатор. По сути, эти два компонента образуют самостоятельный, отдельно стоящий коммутатор, ничего не знающий о других таких же на соседних узлах. БД обеспечивает хранение всей конфигурации своего узла: настройки интерфейсов, портов, различные правила и прочее. Коммутатор, собственно, передает пакеты. Распределенность дизайна OVS достигается с помощью контроллера. Этот компонент обычно разворачивается на отдельный сервер или ВМ.

Используя протокол OpenFlow, OVS-контроллер способен централизованно управлять множеством OVS-коммутаторов, а так же другими устройствами, поддерживающими этот протокол. Таким образом, создается иллюзия, что мы работаем с распределенным по множеству узлов коммутатором. Такая модель кажется мне вполне прозрачной, простой и понятной. Есть множество самостоятельных коммутаторов. Хочешь — используй их как отдельные сущности, а хочешь — подключай к контроллеру и оркестрируй всеми одновременно. В рамках данной статьи будет рассмотрены возможности отдельно стоящего коммутатора без использования контроллера. Настройке управляющего контроллера а так же основам его использования будет посвящена следующая статья. Все материалы http://ivirt-it.ru/open-vswitch-cicle/

#network #виртуализация #openvswitch

CloudStack, это высокоуровневая система управления гетерогенной виртуальной инфраструктурой, которая разработана для удобного управления средами с большим количеством различных гипервизоров, предоставляя удобные механизмы управления. Архитектура CloudSack, изначально сделана многоуровневой и масштабируемой по этому даже для запуска всего одной ВМ необходимо иметь сконфигурированную Зону(Zone), Стойку(Pod), Кластер(Cluster), хотя бы один Хост(Host) в кластере а так же по одному Первичному(Primary) и Вторичному(Secondary) хранилищу.

Перед тем как будет создан и запущен первый instace(ВМ в терминологии CloudStack), стоит отметить, что если все было сделано как в предыдущей статье, то в вашем облаке уже работает несколько ВМ. Эти ВМ-призраки которые не отображаются в разделе Instance являются служебными и увидеть их можно в разделе Infrastructure пункт System VMs. Скорей всего, будут доступны две ВМ тип(Type) у которых будет Console Proxy VM и Secondary Storage VM. Эти служебные ВМ разворачиваются CloudStack'ом из служебного шаблона SystemVM Template(доступен в разделе Templates) по мере необходимости для выполнения тех или иных служебных и фоновых задач. Например ВМ Secondary Storage VM обслуживает все операции связанные с Вторичным хранилищем(Secondary storage) и непосредственно участвует при загрузки новых шаблонов и ISO-образов в CloudStack. Что либо делать с системными ВМ не рекомендуется. CloudStack сам принимает решение когда какая то из ВМ не нужна или наоборот необходимо несколько. Убедитесь, что Secondary Storage VM работает(в сотоянии Running) т. к. без нее загрузка шаблонов и ISO-образов будет не возможной! Далее http://ivirt-it.ru/cloudstack-4-part-3-launchvm/

#cloud computing #cloudstack #cloudos #xenserver #kvm #виртуализация

Инфраструктура CloudStack иерархическая. Наивысшим уровнем иерархии является Зона(Zone) — структура уровня дата-центра.

Зона(Zone) - является крупнейшим подразделением в CloudStack. Зона обычно соответствует одному центру обработки данных, хотя допустимо иметь несколько зон в рамках одного центра обработки данных. Организация инфраструктуры в зонах необходима для обеспечения физической изоляции и избыточности. Например, каждая зона может иметь свой собственный источник питания и сетевое соединение, а также зоны могут быть широко разделены географически (хотя это не обязательно). В рамках одной зоны, спокойно могут работать хосты под управлением разных гепирвизоров.

Стойка(Pod) - является вторым по величине подразделением в CloudStack и представляет из себя аналог физической стойки с серверами. Стойки, содержатся в зонах. Каждая зона может содержать одну или несколько стоек. Содержащиеся внутри стойки кластеры и хосты соответственно всегда находятся в рамках одной подсети.

Клаcтер(Cluster) — является третьим по величине подразделением в CloudStack. Кластеры содержатся в стойках а стойки в свою очередь в зонах. По сути Кластер - это группа физических серверов с однотипной конфигурацией размещенных в одной стойке. Все хосты кластера должны иметь на борту однотипный гипервизор, находится в одной подсети и иметь доступ к одному общему хранилищу. Живая миграция ВМ с одного хоста на другой, без прерывания обслуживания, может быть выполнена только в рамках одного кластера.

Хост(Xost) — Сервер с гипервизором на борту(обычно KVM, Xen или VMware). Хосты обеспечивают вычислительные ресурсы, на которых работают ВМ. Хосты являются самым маленьким подразделением в CloudStack. Хосты содержатся в кластерах, кластеры, в стойках, а стойки, содержатся в зонах. Все просто)

Хранилища(Storages) — могут быть первичными(Primary) и вторичными(Secondary). Вторичные могут быть расположенны только на NFS хранилищах, тогда как первичные также могут быть подключены по iSCSI. Как то еще можно использовать локальные диски сервера CloudStack, но в это тему я не вникал. Первичное хранилище, подключается к кластеру и является общим для всех хостов кластера. На первичном хранилище хранятся диски ВМ. Вторичное хранилище, не подключается не к одному кластеру и хосту соответственно, оно существует на уровне зоны и служит для хранения шаблонов ВМ и ISO'шников. Далее http://ivirt-it.ru/cloudstack-4-bild-cloud/

#cloudstack #cloud computing #cloudos #XenServer #kvm

Trending Blogs

Recently Viewed Blogs

Александр Руденко