зачем кластер raspberry pi
Плюсы и минусы кластера Пи?
Я видел много постов, в которых спрашивалось, как создать «суперкомпьютер» или кластер с Raspberry Pis, но я нашел очень мало о плюсах и минусах создания сети Pis. Я заинтересован в создании собственного небольшого кластера, но у меня есть несколько вопросов.
Будучи кластеризованными, действуют ли RPI как один виртуальный компьютер, или у вас есть индивидуальный контроль над всеми RPI? Один узел контролирует другие?
Есть ли что-нибудь, что может сделать RPI, ограниченный в кластере? Например, я все еще буду контролировать все отдельные порты GPIO?
Насколько быстрее это делает пи? Допустим, я делаю кластер из 2 узлов, разогнанный до 1 ГГц каждый, будет ли у меня процессор «двухъядерный 1 ГГц»? Должен ли кластер быть в двоичных числах? (напр. 1,2,4,8,16,32,64)
Итак, помня об этом и перейдя к конкретным вопросам.
В кластере, так как каждый Pi использует свою собственную копию Linux, каждый Pi будет сохранять локальное управление своими портами GPIO. Я не уверен, как программное обеспечение действительно использовало бы это в параллельной вычислительной среде, но вы здесь.
Кластер на самом деле не делает Pi быстрее, потому что это не один компьютер. То, что вы получаете, это просто способность делать больше одновременно. Вы не ограничены числом, кратным двум. Однако существует реальный практический верхний предел для кластерных компьютеров в зависимости от выполняемых задач. Представьте себе, если вы выполняете параллельный расчет на многих Pis, который требует 200 шагов. Однако каждый следующий шаг требует информации, которую каждый Пи рассчитывает на своем предыдущем шаге. Таким образом, каждый Pi должен получать данные от каждого другого Pi на каждой итерации. В зависимости от количества времени, которое требуется каждой итерации для вычисления, вы можете потратить больше времени на отправку данных, чем на вычисление. Вот почему большинство суперкомпьютеров используют InfiniBandсеть. Это очень быстро, так что вы можете сделать больше расчета. Решение этой проблемы состоит в том, чтобы использовать меньше Pis, но заставлять их выполнять больше работы в каждой итерации, но это может оказаться невозможным в зависимости от вашего алгоритма. Отсюда практический верхний предел. (На Pis это было бы особенно плохо, потому что USB Ethernet довольно медленный.)
Итак, перейдем к практическому применению, распределенному веб-хостингу! Вы можете воспользоваться несколькими Pis здесь, это просто не обычный кластер. Скажем, у вас есть 5 пис. Мы будем называть их GatewayPi, WebPi1, WebPi2, WebPi3 и DataPi. GatewayPi обращен к Интернету и использует Nginix для обработки веб-запросов, но не выполняет никакой обработки. Вместо этого он выполняет балансировку нагрузки., Он использует прокси и случайным образом перенаправляет входящий запрос на WebPi1, WebPi2 или WebPi3. Мы только что утроили мощность нашей веб-инфраструктуры, потому что теперь мы можем обрабатывать больше запросов одновременно. А как насчет DataPi? DataPi подключил жесткий диск, на котором хранятся все наши веб-данные, и работает на сервере NFS. WebPiX устанавливает общий ресурс NFS, чтобы иметь доступ к данным для обработки. Таким образом, мы можем запускать резервные копии только в одном месте и можем сэкономить место на диске.
Я только что описал модель, которую используют крупные компании, такие как Google и Facebook, но уменьшенную до размера Raspberry Pi. Из-за стоимости Pis единственный улов заключается в том, что для этого необходимо создать ту же платформу разработки (но для веб-обслуживания), что и кластер Pis для параллельного программирования. Использование нескольких Pis из-за их сравнительно низкой вычислительной мощности вскоре приводит к снижению производительности и энергопотреблению, поскольку вы стремитесь к обработке больших объемов данных. Но только для обучения? Они идеальны.
Как я собрал домашний кластер Kubernetes на базе Raspberry Pi
Здесь есть поклонники Kubernetes? Я уже довольно давно пользуюсь им как на работе, так и в других местах, где занимаюсь частными проектами, но иногда мне нужно место, где можно быстро и без особых затрат разработать и протестировать новые функции или просто, как говорят, «поиграть с программой», скопировать данные в резервное хранилище, обменяться файлами или сделать что-либо подобное.
Я всё подсчитал и понял, что общая стоимость кластера получается ниже, чем стоимость облачных предложений аналогичной вычислительной мощности с таким же количеством нод. Нужно ли ещё что-то объяснять.
Четыре Raspberry Pi 4B 4GB (каждый по 5548 руб.)
Четыре карты памяти 128 GB U3 (каждая по 2616 руб.)
Один источник питания с несколькими USB-выходами (2777 руб.)
Один корпус для нескольких Pi (2242 руб.)
Не помешает добавить: радиаторы и четыре кабеля USB-B на USB-C.
Почему Raspberry Pi?
TL;DR. Главные причины — цена и вычислительная мощность.
Кластер из четырёх нод учетверяет характеристики каждого из мини-компьютеров (1,5 ГГц, 4 ядра ARM CPU и 4 ГБ RAM), то есть в итоге мы получаем 16 ядер 1,5 ГГц и 16 ГБ RAM.
Подготовка карты памяти
Начинаем с загрузки операционной системы, и это будет самая затратная по времени часть проекта. Большую часть своего времени я работаю с Docker и Kubernetes, и одно из моих любимых занятий — сведение размеров образов Docker к абсолютному минимуму. Чаще всего я пользуюсь Alpine Linux, поэтому свой кластер буду строить именно на этом дистрибутиве.
Заходим в раздел Alpine Linux Downloads и выбираем версию AARCH64 для Raspberry Pi 4 Model B.
Пока загружается дистрибутив, подготовим карту памяти: отформатируем её под файловую систему FAT32. Я — фанат OSX, поэтому, чтобы получить идентификатор диска карты памяти, обычно пользуюсь этой командой:
Чтобы отформатировать всю карту памяти (я назвал её RPI), запустите эту команду:
sudo diskutil eraseDisk FAT32 RPI MBRFormat /dev/diskX
Распакуйте загруженный пакет с Alpine linux и сбросьте его на карту:
Базовая настройка системы
Поздравляю, вы на шаг ближе к миру Kubernetes, и где? У себя дома! Вставьте карту памяти в Raspberry Pi, монитор или телевизор, соедините с клавиатурой и включите питание. После того как система загрузится и предложит войти, в качестве имени пользователя и пароля используйте root. Настройка начинается с этой команды:
Я запускаю кластер в домашних условиях, и на моём маршрутизаторе нет нужного количества свободных портов, поэтому я решил воспользоваться сетью Wi-Fi. Вариантов тут не так много, но в любом случае стоит продумать каждый.
После завершения настройки нужно сделать ещё несколько вещей. Alpine по умолчанию запускается из оперативной памяти, но было бы лучше, если бы наши изменения сохранялись на диске, чтобы после возможных перезагрузок каждый раз не вводить их заново.
Вот что нужно сделать:
Изменить размер раздела FAT32 до разумного минимума — в моём случае я задал 1 ГБ.
Для создания нового загрузочного раздела использовать всё оставшееся свободное место.
Не забыть записать только что сделанные изменения.
Полезное руководство: Как работать с cfdisk.
Чтобы завершить весь процесс, нужно запустить ещё несколько команд:
Обновите записи /etc/fstab
И — последние штрихи после перезагрузки системы: имейте в виду, что, если не включить соответствующие cgroups, шаг kubeadm выполнить не удастся.
И, наконец, очень важная вещь после всех шагов — сделать резервные копии внесённых изменений и перезагрузить систему.
Настройка других системных параметров
Я уже писал выше, что собираюсь использовать кластер Kubernetes в домашних условиях. Но, упреждая ваш вопрос, отвечу: да, он будет работать и в офисной сети, но в этом случае нужно будет ещё кое-что добавить.
Определите с помощью avahi daemon имя узла в локальной сети
Зачем нужен этот шаг? А затем, что гораздо проще запустить команду ssh pi0.local, чем возиться с соответствующим IP-адресом. Сетевые настройки и настройка параметров кластеризации после этого станут намного проще, особенно если отсутствует возможность использования статических IP-адресов.
Разрешить ssh root-доступ
Внесите изменения в файл /etc/ssh/sshd_config — добавьте к нему следующую строку, чтобы предоставить ssh root-доступ.
Установите Docker, Kubernetes и оставшиеся пакеты. Они понадобятся нам позже.
Силы можно сберечь
На этом шаге всё должно быть готово. Последним шагом я выключил Raspberry Pi, вставил карту памяти обратно в ноутбук и создал её образ, чтобы можно было продублировать его на оставшиеся три карты и, таким образом, сэкономить время.
Не забудьте: чтобы не возникали конфликты, нужно изменять содержимое /etc/hostname для каждого вновь создаваемого компьютера. Я назвал компьютеры pi0, pi1 и pi2 (так легче запомнить) и внёс эти имена в локальный конфигуратор ssh (на именование нет никаких ограничений).
Создание мастер-ноды Kubernetes
Если будут возникать любые ошибки, связанные с cgroups, останавливающие процесс инициализации, это значит, что вы наверняка пропустили один из шагов. Если всё сделано правильно, должно появиться сообщение, что инициализация панели управления Kubernetes прошла успешно: Your Kubernetes control-plane has initialised successfully!
Сохраните вывод команды, которая начинается с kubeadm join, в безопасном месте. Она понадобится, чтобы добавить к кластеру оставшиеся ноды.
Для сохранения идентификационных данных в домашнем каталоге выполните эти команды:
Как получить доступ к ноде?
Мастер-нода запущена, что ещё нужно сделать?
Нужно обеспечить сетевую связь между подами — без неё нода будет иметь отметку (taint) и всегда оставаться в состоянии NotReady — “не готова”.
По умолчанию на мастер-ноде ничего развёртывать нельзя, и нода будет отображаться c отметкой (taint), но не волнуйтесь — мы можем изменить это командой
Теперь что касается дашборда. Покажите мне того человека, которому не нравится, когда в ПО имеется дашборд! В Kubernetes есть собственный и достаточно универсальный дашборд, и с его помощью можно обозревать весь кластер и что-либо у него внутри.
Как вы, возможно, заметили, я довольно хорошо покопался в настройках Helm-чарта, но для этого были причины.
Ваш дашборд будет работать, но. он ничего не будет показывать, потому что ещё нет разрешений.
Мы почти у цели. У нас есть мастер-нода и дашборд, но доступа к нему в данный момент у нас нет. Конечно, для доступа к дашборду можно было воспользоваться nodePort, но мы пойдём другим путём — получим доступ средствами Kubernetes, а для этого нам понадобится балансировщик нагрузки loadBalancer.
Нода работает в локальной сети, поэтому мы не можем рассчитывать ни на какие «плюшки» от AWS или GoogleCloud, но бояться тут нечего — эту проблему, в принципе, можно решить.
Балансировка нагрузки в домашней сети
Выполните инструкции по установке из MetalLB до конца раздела Installation By Manifest.
Это команда будет выполняться до тех пор, пока Pi включён. Чтобы не делать лишнюю работу, создавая скрипты запуска, я решил изменить файл /etc/network/if-up.d/dad и установить неразборчивый режим: в нём сетевая плата позволяет принимать все пакеты, независимо от того, кому они адресованы.
Создайте следующий манифест: my-dashboard.yaml
Не забудьте изменить раздел адресов в соответствии с настройками локальной сети.
Теперь в моём случае к дашборду можно получить доступ по адресу http://192.168.50.200/.
Кластер k8s на базе Raspberry Pi.
Эта статья, пронизанная любовью к экспериментам, была написана после дня субботних мучений, скрашенного несколькими банками энергетического напитка.
Обзор подов кластера представлен K9S
Добавление дополнительных нод
Я придерживаюсь принципов DRY (Don’t Repeat Yourself — Не повторяйся) и KISS (Keep It Stupid Simple — Делай проще, тупица), поэтому не буду ничего повторять, а объясню всё простыми словами. Вернитесь к началу статьи и на вновь создаваемых нодах выполните ещё раз все шаги до места “Создание мастер-ноды”, затем запустите следующую команду (не забудьте заменить IP-адрес на IP мастер-ноды или укажите имя узла pi0.local. За эту возможность отдельное спасибо avahi-daemon):
Совет: если вы забыли скопировать команду kubeadm во время создания мастер-ноды, не расстраивайтесь, просто запустите на мастер-ноде следующую команду, и команда kubeadm будет распечатана. А если хотите прокачать себя до DevOps инженера — приходите учиться и станьте дефицитным и очень высокооплачиваемым специалистом.
Узнайте, как прокачаться и в других специальностях или освоить их с нуля:
Профессия Data Scientist
Профессия Data Analyst
Курс по Data Engineering
Другие профессии и курсы
ПРОФЕССИИ
Профессия Fullstack-разработчик на Python
Профессия QA-инженер на JAVA
Профессия Этичный хакер
Профессия C++ разработчик
Профессия Разработчик игр на Unity
Профессия iOS-разработчик с нуля
Профессия Android-разработчик с нуля
КУРСЫ
Курс по Machine Learning
Курс «Machine Learning и Deep Learning»
Курс «Математика для Data Science»
Курс «Математика и Machine Learning для Data Science»
Приключения с домашним Kubernetes-кластером
Прим. перев.: Автор статьи — Marshall Brekka — занимает позицию директора по проектированию систем в компании Fair.com, предлагающей своё приложение для лизинга автомобилей. В свободное же от работы время он любит применять свой обширный опыт для решения «домашних» задач, которые вряд ли удивят любого гика (посему вопрос «Зачем?» — применительно к описанным дальше действиям — априори опущен). Итак, в своей публикации Marshall делится результатами недавнего развёртывания Kubernetes на… ARM-платах.
Как и у многих других гиков, за прошедшие годы у меня накопились разнообразные платы для разработки вроде Raspberry Pi. И как и у многих гиков, они пылились на полках с мыслью, что когда-нибудь пригодятся. И вот для меня этот день наконец-то настал!
Во время зимних каникул появились несколько недель вне работы, в рамках которых было достаточно времени для того, чтобы инвентаризировать всё накопленное железо и решить, что с ним делать. Вот что у меня было:
Жизненные цели
Поскольку работа с RAID не была оптимальной при использовании нетбука, я задался следующими целями для получения лучшей конфигурации:
Решив свои аппаратные потребности (и ожидая прибытия этого решения), я переключился на вторую цель.
Управление софтом на устройстве
Отчасти мои прошлые проекты, связанные с платами для разработки, провалились по причине недостаточного внимания к вопросам воспроизводимости и документирования. При создании очередной конфигурации под свои текущие потребности я не утруждал себя записывать ни предпринятые шаги, ни ссылки на публикации в блогах, которым следовал. И когда, спустя месяцы или годы, что-то шло не так и я пытался исправить проблему, у меня не было понимания, как всё изначально устроено.
Поэтому я сказал себе, что уж на этот раз всё будет иначе!
И обратился к тому, что достаточно хорошо знаю,— к Kubernetes.
Хоть K8s и является слишком тяжелым решением достаточно простой проблемы, после почти трёх лет управления кластерами с помощью разных средств (собственных, kops и т.п.) на основной работе я очень хорошо знаком с этой системой. К тому же, развернуть K8s вне облачного окружения, да ещё и на ARM-устройствах — всё это представлялось интересной задачей.
Я также подумал, что, поскольку имеющееся в распоряжении железо не удовлетворяет необходимым требованиям для NAS, попробую хотя бы собрать из него кластер и, возможно, некоторый софт, который не так требователен к ресурсам, будет в состоянии работать на старых устройствах.
Kubernetes на ARM
На работе у меня не было возможности использовать утилиту kubeadm для разворачивания кластеров, поэтому я решил, что сейчас самое время попробовать её в действии.
В качестве операционной системы был выбран Raspbian, поскольку он славится лучшей поддержкой имеющихся у меня плат.
Я нашёл хорошую статью по настройке Kubernetes на Raspberry Pi с использованием HypriotOS. Поскольку не был уверен в доступности HypriotOS для всех своих плат, я адаптировал эти инструкции под Debian/Raspbian.
Необходимые компоненты
Для начала потребовалась установка следующих инструментов:
После этого я установил компоненты Kubernetes по инструкциям из блога Hypriot, проведя их адаптацию с тем, чтобы для всех зависимостей использовались конкретные версии:
Raspberry Pi B
Первая же сложность возникла при попытке bootstrap’а кластера на Raspberry Pi B:
Выяснилось, что в Kubernetes убрали поддержку ARMv6. Ну что ж, у меня есть ещё CubbieBoard и Banana Pi.
Banana Pi
Изначально казалось, что такая же последовательность действий для Banana Pi будет успешнее, однако команда kubeadm init завершилась таймаутом при попытке дождаться рабочего состояния control plane:
Очевидно, api-server умирал или же стронний процесс убивал и перезапускал его.
Проверяя логи, я увидел весьма стандартные процедуры по запуску — была запись о начале прослушивания безопасного порта и продолжительная пауза перед появлением многочисленных ошибок в TLS-рукопожатиях:
И вскоре после этого сервер завершает свою работу. Гугление привело к такой проблеме, указывающей на возможную причину в медленной работе криптографических алгоритмов на некоторых ARM-устройствах.
Вынос этих файлов из директории с манифестами скажет kubelet’у остановить выполнение соответствующих pod’ов:
Просмотр последних логов api-server показал, что теперь процесс пошёл дальше, однако всё равно умирал примерно через 2 минуты. Тогда мне вспомнилось, что манифест мог содержать liveness-пробу с таймаутами, имеющими слишком низкие значения для такого медлительного устройства.
Поэтому проверил /etc/kubernetes/manifests/kube-api-server.yaml — и в нём, конечно же…
Pod убивался через 135 секунд ( initialDelaySeconds + timeoutSeconds * failureThreshold ). Повышаем значение initialDelaySeconds до 120…
Успех! Ну, ошибки в рукопожатиях всё ещё происходят (предположительно от kubelet), однако запуск всё равно состоялся:
Когда api-server поднялся, я переместил YAML-файлы для контроллера и планировщика обратно в директорию манифестов, после чего они уже тоже нормально стартовали.
Да, всё работает, хотя такие старые устройства, по всей видимости, не предназначались для запуска control plane, поскольку повторяющиеся TLS-подключения вызывают значительные тормоза. Так или иначе — рабочая инсталляция K8s на ARM получена! Поехали дальше…
Монтирование RAID’а
Поскольку SD-карты не подходят для записи в долгосрочной перспективе, для самых изменчивых частей файловой системы я решил использовать более надёжное хранилище — в данном случае это RAID. На нём были выделены 4 раздела:
Прибытие ROC-RK3328-CC
Отлично! Никакой возни с таймаутами.
А поскольку на этой плате тоже будет использоваться RAID, снова потребуется настройка mount’ов. Подытожу все шаги:
1. Монтирование дисков в /etc/fstab
2. Установка бинарников Docker и K8s
3. Настройка уникального имени хоста (важно, т.к. добавляется множество узлов)
4. Инициализация Kubernetes
Опускаю фазу с control plane, поскольку хочу иметь возможность планирования нормальных pod’ов и на этом узле:
5. Установка сетевого плагина
Информация об этом в статье Hypriot была немного устаревшей, поскольку сетевой плагин Weave теперь тоже поддерживается на ARM:
6. Добавление лейблов узла
На этом узле я собираюсь запустить сервер NAS, поэтому помечу его лейблами для возможности дальнейшего использования в планировщике:
Подключение других узлов к кластеру
Поиск Docker-контейнеров для ARM
Сборка большей части нужных Docker-контейнеров нормально проходит на Mac’е, однако для ARM всё несколько сложнее. Найдя множество статей о том, как использовать для этих целей QEMU, я всё же пришёл к тому, что большинство нужных мне приложений уже есть в собранном виде, и многие из них доступны на linuxserver.
Следующие шаги
Всё ещё не получив начальную конфигурацию устройств в настолько автоматизированном/заскриптованном виде, как хотелось бы, я хотя бы составил набор основных команд (mount’ы, вызовы docker и kubeadm ) и и задокументировал их в Git-репозитории. Остальные используемые приложения тоже получили YAML-конфигурации для K8s, хранимые в том же репозитории, так что получить необходимую конфигурацию с нуля теперь очень просто.
В перспективе же мне хотелось бы добиться следующего:
Зачем кластер raspberry pi
Проект Raspberry Pi очень популярен, а в последнее время, с появлением в серии достаточно серьёзных процессоров на базе ядер ARM Cortex-A72, всё большую популярность набирает идея кластера из таких плат. Кластер Turing Pi мы описывали ещё в прошлом году, а сейчас анонсирована новая, вторая версия, уже на базе современного варианта «малины».
Изначально Turing Pi представлял собой своеобразную «системную плату», в которую можно было установить до семи модулей Raspberry Pi Compute Module 3/3+. Такой кластер мог питаться от стандартного блока питания ATX и содержал на борту собственный сетевой коммутатор на чипе Realtek.
В некотором смысле Turing Pi 2 можно воспринимать, как шаг назад — новая версия подразумевает использование всего четырёх вычислительных узлов, однако не стоит забывать, что Raspberry Pi 4 Compute Module существенно мощнее. Новинка использует полноценную архитектуру ARM v8 (BCM2711, 4 ядра, 1,5 ГГц) и каждый модуль может нести на борту 8 Гбайт оперативной памяти, что суммарно даёт 32 Гбайт на мини-кластер.
Разработчики называют Turing Pi 2 минимальным «строительным блоком» для инфраструктуры на базе Raspberry Pi. При этом говорится, что первый вычислительный узел может служить хостом для десктопной операционной системы, например, Ubuntu Desktop LTS, а три других — использоваться для компиляции и отладки разрабатываемого под архитектуру ARM серверного программного обеспечения. Впоследствии его можно перенести на другие ARM-платформы, например, AWS Graviton, поскольку Turing Pi 2 имеет аналогичную архитектуру.
Хотя Raspberry Pi Compute Module 4 имеет новый разъём, его по-прежнему можно установить вертикально с помощью переходника Gumstix Raspberry Pi CM4 Uprev, который к тому же может иметь на борту тензорный сопроцессор Google Coral.
В итоге плату для нового кластера удалось уместить в форм-фактор Mini-ITX. На ней имеется два слота mPCIe, два разъёма SATA 3.0, видеовыходы HDMI и MIPI DSI, а также пара портов Gigagit Ethernet. За сеть отвечает набортный коммутатор 2 уровня, что делает Turing Pi 2 аккуратной и законченной системой; к сожалению, скорость сети по-прежнему ограничена 1 Гбит/с. Начало поставок Turing Pi 2 намечено на начало следующего года.
Raspberry Pi Zero Cluster Board: вычислительный кластер на основе Pi Zero
Idein, стартап из Японии, сейчас разрабатывает вычислительный модуль с Raspberry Pi Zero. Цель — создание Actbulb, мультифункционального устройства для решения различных задач, включая анализ данных. Этот девайс предназначен для работы в «умных» домах, и должен быть очень небольшим, размещать его планируется в обычном патроне для обычной лампочки.
Пока что все находится в стадии проектирования, и компания решила создать первый прототип на основе 16 Raspberry Pi Zero. По задумке, должен получиться настоящий вычислительный кластер, способный решать множество задач.
We’ve almost finished creating PiZero cluster board. But I wonder when we can buy remaining 15 PiZeros. #PiZero pic.twitter.com/mvHyoonlix
Для того, чтобы собрать все «малинки» вместе, была создана специальная плата с 32 micro-USB портами. Для каждой мини-платы предназначено по 2 порта. Один для питания — другой для обмена данными. Кроме того, здесь 16 Ethernet разъемов.
«Мы создаем сенсор, который использует вычислительный модуль Raspberry Pi. Поэтому нам нужно много „малинок“ для разработки и тестов. Мы используем мини-ПК для обработки изображений, глубокого обучения и других задач. Нам нужны реальные Pi, но не только для работы с ними в качестве Linux машин», — говорит разработчик проекта.
Как можно видеть, на плате сейчас только одна «малинка», просто потому, что у компании нет большего количества, а платы не продаются в открытом доступе. Теперь компания собирает «с миру по нитке», и после того, как соберут все 16 мини-ПК, кластер заработает в полную силу.
Сам кластер уже планируется продавать, добавив Ethernet свитч, GPIO, HDMI и прочее.
В Twitter основателя компании идет активное обсуждение идеи, так что можно предложить что-то и от себя, если есть желание.