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

О себе: Опыт администрирования ceph с версии hammer, основатель комьюнити t.me/ceph_ru в телеграм.

Дабы не быть голословным я буду ссылаться на принятые хабром (судя по рейтингу) посты о проблемах с ceph. С бОльшей частью проблем в этих постах я тоже столкнулся. Ссылки на использованный материал в конце поста.

В посте про Rook мы упоминаем ceph не просто так — Rook по сути ceph завернутый в kubernetes, а значит наследует все его проблемы. С проблем ceph и начнем.

Часть 2/3 тут
Часть 3/3 тут

Всем привет! В этой статье я хочу упорядочить информацию и поделиться опытом создания и использования внутреннего кластера Kubernetes.

За последние несколько лет эта технология оркестровки контейнеров сделала большой шаг вперед и стала своего рода корпоративным стандартом для тысяч компаний. Некоторые используют ее в продакшене, другие просто тестируют на проектах, но страсти вокруг нее, как ни крути, пылают нешуточные. Если еще ни разу ее не использовали, самое время начать знакомство.

0. Вступление

Kubernetes — это масштабируемая технология оркестровки, которая может начинаться с установки на одной ноде и достигать размеров огромных НА-кластеров на основе нескольких сотен нод внутри. Большинство популярных облачных провайдеров представляют разные виды реализации Kubernetes — бери и пользуйся. Но ситуации бывают разные, и есть компании, которые облака не используют, а получить все преимущества современных технологий оркестровки хотят. И тут на сцену выходит инсталляция Kubernetes на «голое железо».

Часть 1/3 тут
Часть 3/3 тут

Привет и с возвращением! Это вторая часть статьи о настройке кластера Kubernetes на «голом железе». Ранее мы настраивали НА-кластер Kubernetes с помощью внешнего etcd, схемы «ведущий-ведущий» и балансировки нагрузки. Ну а теперь пришло время настроить дополнительную среду и утилиты, чтобы сделать кластер полезнее и максимально приближенным к рабочему состоянию.

В этой части статьи мы сосредоточимся на настройке внутреннего балансировщика нагрузки сервисов кластера — это будет MetalLB. Также мы установим и настроим распределенное хранилище файлов между нашими рабочими нодами. Будем использовать GlusterFS для постоянных томов, которые доступны в Kubernetes.
После выполнения всех действий схема нашего кластера будет выглядеть следующим образом:

Часть 1/3 тут.

Часть 2/3 тут.

Всем привет! А вот и третья часть руководства «Kubernetes на «голом железе»! Я уделю внимание мониторингу кластера и сбору логов, также мы запустим тестовое приложение для использования предварительно настроенных компонентов кластера. Затем проведем несколько стресс-тестов и проверим стабильность этой кластерной схемы.

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

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


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

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

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

Но с такими возможностями часто приходит полное отсутствие уважения к участникам проекта других профессий. Это отсутствие уважения может оказаться настолько глубоким, что порождает в уме разработчика твёрдую уверенность, что он не только самый ценный участник программного проекта, но и необходим компании в целом. К сожалению, хотя лишь малое число разработчиков способны накапливать что-либо напоминающее богатство, многие ведут себя так, словно они следующие Марк Цукерберг, Билл Гейтс или Стив Джобс; хотя это очень далеко от истины. Это приводит к личностным проблемам, которые так же увлекательно наблюдать со стороны, как страшно созерцать в себе.

Будучи инфраструктурным инженером в команде разработки облачной платформы, мне довелось поработать со многими распределенными системами хранения данных, в том числе и с теми, что указаны в заголовке. Кажется, что есть понимание их сильных и слабых сторон, и я попробую поделиться с вами своими мыслями на этот счет. Так сказать, посмотрим у кого хеш-функция длиннее.

Преподаватели Binary District подготовили список книг для будущих студентов курса Project Management in IT: это база, способная сделать из хорошего управленца лучшего. Список настолько хорош, что по крайней мере половину книг можно смело рекомендовать вообще всем, кто хочет стать лучшей версией себя.

Привет, меня зовут Максим, я системный администратор. Три года назад мы с коллегами начали переводить продукты на микросервисы, а в качестве платформы решили использовать Openstack, и столкнулись с некоторым количеством неочевидных граблей при автоматизации тестовых схем. Этот пост про нюансы настройки OpenStack, которые с трудом находятся на пятой странице выдачи поисковика (а лучше, чтобы легко находились на первой).

Нагрузка на ядра: было — стало

NAT

В некоторых инстансах мы используем dualstack. Это когда виртуальная машина получает сразу два адреса — IPv4 и IPv6. Сначала мы сделали так, что «плавающий» v4-адрес назначался во внутренней сети через NAT, а v6 машина получала через BGP, но с этим есть пара проблем.

NAT — дополнительный узел в сети, где и без него нужно следить за нормальным распределением нагрузки. Появление NAT в сети почти всегда ведёт к сложностям с отладкой — на хосте один IP, в базе другой, и отследить запрос становится сложно. Начинаются массовые поиски, а разгадка всё равно будет внутри OpenStack.

Ещё NAT не позволяет сделать нормальную сегментацию доступов между проектами. У всех проектов свои подсети, плавающие IP постоянно мигрируют, и с NAT управлять этим становится решительно невозможно. В некоторых инсталляциях говорят об использовании NAT 1 в 1 (внутренний адрес не отличается от внешнего), но это всё равно оставляет лишние звенья в цепочке взаимодействия с внешними сервисами. Мы пришли к мнению, что для нас лучший вариант — это BGP сеть.

Я люблю Ceph. Я работаю с ним уже 4 года (0.80.x — 12.2.6, 12.2.5). Порой я так увлечен им, что провожу вечера и ночи в его компании, а не со своей девушкой.
 Я сталкивался с различными проблемами в этом продукте, а с некоторыми продолжаю жить и по сей день. Порой я радовался легким решениям, а иногда мечтал о встрече с разработчиками, чтобы выразить свое негодование. Но Ceph по-прежнему используется в нашем проекте и не исключено, что будет использоваться в новых задачах, по крайней мере мной. В этом рассказе я поделюсь нашим опытом эксплуатации Ceph, в некотором роде выскажусь на тему того, что мне не нравится в этом решении и может быть помогу тем, кто только присматривается к нему. К написанию этой статьи меня подтолкнули события, которые начались примерно год назад, когда в наш проект завезли Dell EMC ScaleIO, ныне известный как Dell EMC VxFlex OS.

Это ни в коем случае не реклама Dell EMC или их продукта! Лично я не очень хорошо отношусь к большим корпорациям, и черным ящикам вроде VxFlex OS. Но как известно, всë в мире относительно и на примере VxFlex OS очень удобно показать каков Ceph с точки зрения эксплуатации, и я попробую это сделать.

История началась год назад, когда к нам пришёл наш друг, коллега и большой эксперт по энтерпрайз стораджам со словами: «Парни, у меня тут завалялась шикарная хранилка со всеми модными фичами. 90Tb». Особой необходимости мы в ней не видели, но, естественно, отказываться не стали. Настроили туда пару бекапов и на какое-то время благополучно забыли.

Периодически возникали задачи типа переброса больших файлов между хостами, сборка WAL для реплик Postgre и т. д. Постепенно мы начали перекладывать в этот холодильник всё разбросанное добро, так или иначе связанное с нашим проектом. Настроили ротейт, оповещения об успешных и не очень попытках выполнения бекапа. За год эта хранилка стала одним из важных элементов нашей инфраструктуры в группе эксплуатации.

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

Выбор был небольшой — распихивать всё опять куда попало либо собирать свой собственный холодильник из блэкджека и палок. К этому моменту мы уже были наученные, насмотрелись на множество не совсем отказоустойчивых систем, и отказоустойчивость стала нашим вторым я.

Из множества вариантов наш взгляд особенно зацепил Глустер, Гластер. Всё равно, как называть. Лишь бы результат был. Поэтому мы начали над ним измываться.

В середине 2014 года мы в приняли решение о необходимости переноса услуг публичного сервиса аренды виртуальных машин (далее сервис VPS) с платформы OpenQRM, которая была выбрана на тот момент без должного анализа потребностей клиентов и не отвечала требованиям как к управляемости так и к философии поведения (надо сказать, что разработчики OpenQRM вообще странно подошли к разработке, создав продукт из кучи bash-скриптов, кода на PHP и кучи костылей). В общем, наши пользователи были несчастливы, сервис был так себе и приносил скорее убытки, чем прибыль. Необходимо отметить, что наша дочерняя компания, которая как раз оказывает операторские услуги — небольшая региональная компания и мы не рассматривали создание большого сервиса VPS в тот момент, а основной задачей виделось переход на стабильный и надежный продукт, который бы отвечал следующим требованиям:

• простота в развертывании и настройке для нужд сервиса VPS;
• готовность к использованию и достаточно широкая база пользователей;
• простота в диагностике ошибок;
• удобный пользовательский интерфейс;
• API для управления виртуальными машинами.

Размер инфраструктуры не планировался большим — на тот момент мы рассчитывали использовать 512 — 1024 ГБ RAM, 128 — 256 ядер Xeon E5-2670, 10 — 20 ТБ хранилища, 200+ виртуальных машин. Сервис предполагал предоставление виртуальных машин с непосредственным присвоением публичных IPv4, о поддержке IPv6 речь не шла. В качестве технологии виртуализации мы ориентировались на KVM. Хранилище — классическое NFSv3.

Apache CloudStack представляет собой универсальную платформу управления средами выполнения виртуальных машин (часто такие продукты именуются “панель управления облаком VPS”). Использование Apache CloudStack (далее, ACS) дает администратору возможность развернуть облако с требуемыми сервисами в короткий срок, а после развертывания эффективно управлять облаком в течение всего жизненного цикла. В рамках данной статьи даются рекомендации по дизайну облака, который может использоваться на практике и подходит для большинства провайдеров публичных облаков, планирующих построение публичных облачных сред малых и средних размеров, обладающих максимальной простотой администрирования и не требующих специальных знаний для отладки и обнаружения проблем. Статья не является пошаговым руководством настройки Apache CloudStack.

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

Облако с описанным в статье дизайном успешно используется для оказания коммерческих услуг по аренде VPS. В рамках облака развернуто хранилище на 16 ТБ, состоящее полностью из SSD накопителей Samsung Pro 850 1TB, организованное в программный RAID6, 176 ядер Xeon E5-2670, 768 GB RAM, сеть на 256 публичных адресов.

После моих первой и второй статей об Apache CloudStack ко мне обратился пользователь с вопросом о том, как организовать высокодоступный управляющий сервер ACS с использованием Galera. Ранее я не использовал такую топологию развертывания, но по этому поводу решил попробовать выполнить такую настройку.

В статье описывается метод развертывания отказоустойчивой конфигурации управляющих серверов Apache CloudStack совместно с мультимастер-кластером MariaDB (Galera).

Данная статья является переводом очень хорошего топика с форума Stack Overflow. Так как английский язык не является для меня родным, то какие-либо непонятные мне места я просто пропускал, что бы не разгневать тех, кто его действительно знает. Статья содержит список советов и рекомендаций для начинающих разработчиков под Android.

Представляю вашему вниманию перевод статьи "Mobile Form Design Strategies" от Chui Chui Tan. Перевели в компании UXDepot. Специально для пользователей Хабрахабра с одобрением издания UX Booth.

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

Интернет на экране мобильного телефона находится под влиянием нескольких важных факторов:

• Окружающей среды — человек может пользоваться гаджетом в толпе, в режиме цейтнота или на ярком свету (соответственно, качество изображения на экране ухудшается)
• Сети — соединение может быть медленным и ненадежным
• Особенностей девайса — например, маленького экрана устройства

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

Инвентарь

Нам понадобится текстовый редактор (я выбрал Gusto, хотя можно было использовать, например, Textastic), графический редактор (установил на всякий случай сразу два: Adobe Photoshop Express и PhotoPad, оба бесплатные), приложение Яндекс.Фотки для загрузки картинок в интернет, и CSS3Machine — про нее расскажу прямо сейчас.

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