Справедливости ради, у wsl2 уже под капотом обычная виртуалка на hyper-v, соответственно сделать можно все, что позволит hyper-v и kernel/userspace, что внутри wsl2 гостя ( с этим ограничений тоже нет).
Другое дело, что так в каждой ОС можно сделать: отличие от того, чтобы самому развернуть vm, используя нативный гипервизор, и поставить туда нужный дистр, только в том, что это идет из коробки с интеграцией в хостовую систему (маунты plan9 внутрь гостя и всякое такое). Но опять же, ничего такого, что сложно сделать самому.
Да, но если бы дело было только в этом, то тогда бы как праймари использовался cloudfront. А так на свой cdn переключились только после того, как сторонний перестал работать.
Ядро используется хостовое, и запустить вы сможете внутри jail только тот набор userspace приложений, который может работать с текущим хостовым ядром. Понятно, что это может быть и linux userspace, если хостовое ядро собрано с linux_enable=«YES».
Непонятно также почему выбран Virtio-Block, хотя прокс рекомендует Virtio-Scsi.
Именно в вопросе производительности это не сильно важно. Proxmox рекомендует virtio-scsi скорее из-за большего количества функций (полноценное scsi устройство, поддержка blkdiscard, масштабируемость и т.д.) при примерно той же производительности (при некоторых паттернах нагрузки она хуже из-за большего количества прослоек).
Это, как и ceph — распределнное программно определяемое хранилище, т.е. другой тип решений. Обсуждалась же классическая централизованная блочная СХД.
«2-х узловую резервированную СХД» на 30% дешевле
Резервированную? Т.е. поверх будет еще синхронная репликация? Тогда это, опять же, другой тип решений с другим показателем производительности. Обсуждалась реализация аналога 2ух котроллерной СХД, когда каждый узел одновременно видит все диски из jbod. Диски для этого должны быть с SAS интерфейсом (по path на каждый узел СХД) и jbod, подключенный по SAS одновременно к 2ум узлам. В этом случае мы одновременно используем 2 узла, балансируем между ними нагрузку (каждый держит разные raid'ы, раздает разные луны), и при этом не нужна никакая ухудшающая производительность репликация. Тут по ценнику может быть тоже самое, но при этом меньше функционала (который не всегда, конечно, нужен), отсутствие кэша (аппаратный raid с батарейкой и кэшем не подойдет, т.к. с ним не реализовать 2ух узловой режим работы без доп. механизмов репликации).
О NVMe и говорить не нужно, в этом случае аналог 2ух контроллерной вендорской СХД особо собрать и не получится (как диски по PCIe одновременно на 2 сервера пробрасывать).
Я, «грамотный инженер» который успешно эксплуатировал комплект как СХД
Имеются в эксплуатации всевозможные типы SAN: самодельные на базе supermicro без репликации (2x 2U head, lsi hba, Nx 4U jbods via sas, software: mdadm,lvm,scst_target), самодельные на базе supermicro c репликацией (2x 4U head, lsi hba, software: drbd, mdadm,lvm,scst_target), различные вариации вышеперечисленного, различные вендорские СХД. Конечно, 2x 4U Supermicro сервера с drbd репликацией будут в разы дешевле стоить готовой СХД, ну так и производительность будет совсем другая. При приближении функционала сравнивается и цена.
Примерный порядок розничных цен для стандартных компонентов я привёл ниже.
Так нужны SAS SSD, чтобы все диски были доступны с 2ух «голов» СХД для возможности online переезда RAID'а (если мы хотим получить аналогичное вендорскому решение). А они будут намного дороже, особенно если схожих с Optane характеристик. В случае с SATA дисками кроме RAID'а нужен будет еще механизм синхронной репликации, а это сразу просадка по производительности, и уже сравнивать с вендорской 2ух котроллерной СХД нельзя.
против одиночной «брендовой»
Так не одиночная же. Обычно берут 2ух контроллерную, а это аналог 2ух узлов в самодельном SAN'е.
мы получим стоимость более чем в 2 раза меньше
Вот как раз если попытаться повторить один в один вендорскую СХД (например какую-нибудь OceanStor Dorado5000 V3) с близки показателями по iops, latency, доступности, то будет сопоставимо по цене (заоблочные цены из статьи не рассматриваем), но при этом может быть меньшая функциональность (тот же dedup мало где нормально работает, да еще чтобы без просадки по производительности).
«грамотный инженер» за 100k в месяц соберёт более производительную и оптимизированную под конкретные задачи клиента систему на железе от «дешманского» Supermicro с парой запасных узлов и резервированием СХД в 2 раза дешевле
В сравнении вендорских СХД и тех, которые можно построить самостоятельно на базе того же Supermicro, не все так однозначно.
Например, вендорская СХД: 2 контроллера, куча RAM кэша, рабочие dedup/compression, thin volumes, различные программные прослойки для удобства управления дисками, массивами и т.д.
Чтобы построить что-то хоть немного аналогичное: нужно 2x сервера c HBA и производительными CPU, шареный jbod, подключенный к головам по SAS, различная мелочевка для коммутации этого всего, ну и, собственно, SAS диски (SAS-SSD от любого вендора будут не дешевыми). По программной части будет что-нибудь типа: mdadm — lvm — iscsi_target. По итогу: нету RAM кэша (мы же не можем рисковать, с отдельным сервером может случиться что угодно), нету dedup/compression, с mdadm+lvm нельзя добиться такой гибкости и такого функционала, какой есть в вендорских СХД (пример). При этом по цене не факт, что получится дешевле, особенно вместе с SAS-SSD дисками.
Альтернативой может быть ceph, но его грамотная поддержка потребует больше ресурсов и более квалифицированный персонал чем первые 2 варианта. Желательно разбираться в кодовой базе ceph, возможно понадобится вносить правки, тестировать все это.
Да, я поспешил. У вас в статье с этим все правильно. Просто бросилось в глаза «write utils», это и смутило. Не заметил дальше, что берется именно «write ticks», т.е. суммарное время всех w_io операций.
А в чем смысл вычислять производную от iops и util метрику *_svctime, если ядро предоставляет информацию о суммарном затреченном времени на все дисковые операции (в /sys/block/sdX/stat поля read ticks, write ticks или в /proc/diskstat аналоничные по смыслу поля). Делим на количество io в еденицу времени и получаем честный средний latency (await).
В случае с *_svctime цифра может не иметь ничего общего с реальным latency. Наример: за 1 секунду было сделано 5 параллельных r_io опреаций, каждая выполнялась 1 секунду. Реальный средний r_latency (и посчитанный исходя из 5ти секунд read ticks) — 1 секунда, r_svctime же будет 1/5 = 0.2 секунды.
bgp тут как универсальное и специально для этих дел оптимизированное средство доставки маршртов на целевую систему. Т.е. если из статьи убрать bgp, то нужны будут другие способы доставки маршрутов. Например кастомный скрипт, который считает diff новых/страрых маршрутов и заливает на роутер через expect по ssh разницу (не перезаливать же каждый раз 60k маршрутов). Разные роутеры — разные expect скрипты.
Способов много можно придумать, у каждого будут свои плюсы и минусы в конкретной ситуации.
Глупо загонять такое количество адресов в таблицу машрутизации.
Наоборот непонятно, зачем городить дополнительные сущности в виде iptables, ipset и ip_rules, если у нас уже есть dst, которые достаточно добавить в дефолтную таблицу маршрутизации.
Откдуда взято предположение, что jenkins hash ipset'а будет производительние и экономичнее чем модифицированный LPC-trie для обработки одинакового количества ipv4 адресов/подсетей (неплохое описание и тесты, да и на хабре писали)? Т.е. если ядерная маршрутизация не справится, то с iptables+ipset+ip_rules лучше не будет. Другое дело, что надо смотреть версию ядра, раньше hash использовался для таблицы маршрутизации и некоторые оптимизации позже появились.
Если нужно только отследить связи parent->child, то хватит и ps с флагом f (-H). В варианте автора еще показывается, через что общаются между собой процессы, если общаются.
Так а зачем на них идти? Речь идет об использовании модуля raw для изначальной инсталляции python 2.x, если отсутствует /usr/bin/python. Т.е. добавляется дополнительный task в «bootstrap» playbook.
Python 3 support is being worked on but some Ansible modules are not yet ported to run under Python 3.0. This is not a problem though as you can just install Python 2 also on a managed host.
И в документации поддержка python 3.x все еще помечена как technology preview feature.
Сделать-то можно, но точной консистентности данных не получится. Можно, конечно, остановить все сервисы и сделать remount root'а в read only, но легче ребутнуться и сделать финальный rsync из live окружения и гарантировать консистентность. Ведь все равно сервисы будут недоступны и в первом варианте.
А что, по вашему, делает pvmove? Создается raid через тот же dm-raid и дальше только мониторится процесс синка с заданным интервалом. Мало того, процесс pvmove можно спокойно «прибивать» сразу после запуска, на синк это никак не повлияет (сам процесс синка можно будет мониторить, например, так: dmsetup status|grep mirror). Pvmove только меняет lvm метаданные, создает raid и по окончанию меняет метаданные снова и разваливает raid.
Еще забыл упомянуть: в статье не помечено, но т.к. переезд осуществляется на ssd, то уже на перенесенной системе нужно не забыть включить функционал trim'а (например так: systemctl enable fstrim.timer, для trim'а раз в неделю в рассматриваемом дистрибутиве).
Для того, чтобы разрешить удалённый доступ, необходимо задать пароль для пользователя root и запустить SSH демон
Если говорить о redhat-производных дистрибитивах, то можно на этапе загрузки добавить опции в commandline ядра: inst.sshd inst.vnc inst.vncpassword=pass. Ssh, правда, будет беспарольный, и если сеть недоверенная, то после первого захода лучше установить пароль. Этот способ удобней, если используется не livecd, а какой-нибудь minimal/netinstall и не будет подготовленных конфигов для запуска ssh с помощью systemd/init сервиса + есть vnc, если хочется графики.
задача могла бы быть ещё проще — в логический том добавляется новый диск, после чего с использованием команды pvmove данные переносятся на другой физический носитель внутри логического тома
Тут небольшая путаница. Новый диск (его раздел) добавляется в физичесий том, физический том в логическую группу томов (расширяется существующая), и затем логический том переносится внутри логической группы на другий физический носитель (физичесий том).
Единственное, что осталось сделать, это переустановить загрузчик. Это необходимо делать с использованием chroot
Можно и без chroot, у grub2-install есть опция --boot-directory. В том числе актуально, если под рукой есть только x86 live, а препарируемая система — x86_64 и chrot'нуться не получится.
Ну и как говорили выше, намного универсальней будет использовать rsync, например с опциями --delete --numeric-ids -aHAXS (сохраняем все возможные атрибуты в неизменном виде), тогда мы не зависим от фс между которыми перенос. Если сервер выключен, то ничего exclud'ить не надо. А если нужно минимизировать время простоя, то обычно делают 3ой rsync (в live режиме с exclud'ами, еще раз, чтобы синхронизировать разницу, которая накопилась во время первого прогона и 3ий раз после выключения).
Справедливости ради, у wsl2 уже под капотом обычная виртуалка на hyper-v, соответственно сделать можно все, что позволит hyper-v и kernel/userspace, что внутри wsl2 гостя ( с этим ограничений тоже нет).
Другое дело, что так в каждой ОС можно сделать: отличие от того, чтобы самому развернуть vm, используя нативный гипервизор, и поставить туда нужный дистр, только в том, что это идет из коробки с интеграцией в хостовую систему (маунты plan9 внутрь гостя и всякое такое). Но опять же, ничего такого, что сложно сделать самому.
Да, но если бы дело было только в этом, то тогда бы как праймари использовался cloudfront. А так на свой cdn переключились только после того, как сторонний перестал работать.
Забавное в этой ситуации, что один cdn провайдер использует другого cdn провайдера для своего сайта. Так себе реклама cloudfront'у.
Хотя после инцидента с fastly пока обратно вернулись на свой cdn.
Ядро используется хостовое, и запустить вы сможете внутри jail только тот набор userspace приложений, который может работать с текущим хостовым ядром. Понятно, что это может быть и linux userspace, если хостовое ядро собрано с linux_enable=«YES».
Это, как и ceph — распределнное программно определяемое хранилище, т.е. другой тип решений. Обсуждалась же классическая централизованная блочная СХД.
Резервированную? Т.е. поверх будет еще синхронная репликация? Тогда это, опять же, другой тип решений с другим показателем производительности. Обсуждалась реализация аналога 2ух котроллерной СХД, когда каждый узел одновременно видит все диски из jbod. Диски для этого должны быть с SAS интерфейсом (по path на каждый узел СХД) и jbod, подключенный по SAS одновременно к 2ум узлам. В этом случае мы одновременно используем 2 узла, балансируем между ними нагрузку (каждый держит разные raid'ы, раздает разные луны), и при этом не нужна никакая ухудшающая производительность репликация. Тут по ценнику может быть тоже самое, но при этом меньше функционала (который не всегда, конечно, нужен), отсутствие кэша (аппаратный raid с батарейкой и кэшем не подойдет, т.к. с ним не реализовать 2ух узловой режим работы без доп. механизмов репликации).
О NVMe и говорить не нужно, в этом случае аналог 2ух контроллерной вендорской СХД особо собрать и не получится (как диски по PCIe одновременно на 2 сервера пробрасывать).
Имеются в эксплуатации всевозможные типы SAN: самодельные на базе supermicro без репликации (2x 2U head, lsi hba, Nx 4U jbods via sas, software: mdadm,lvm,scst_target), самодельные на базе supermicro c репликацией (2x 4U head, lsi hba, software: drbd, mdadm,lvm,scst_target), различные вариации вышеперечисленного, различные вендорские СХД. Конечно, 2x 4U Supermicro сервера с drbd репликацией будут в разы дешевле стоить готовой СХД, ну так и производительность будет совсем другая. При приближении функционала сравнивается и цена.
Так нужны SAS SSD, чтобы все диски были доступны с 2ух «голов» СХД для возможности online переезда RAID'а (если мы хотим получить аналогичное вендорскому решение). А они будут намного дороже, особенно если схожих с Optane характеристик. В случае с SATA дисками кроме RAID'а нужен будет еще механизм синхронной репликации, а это сразу просадка по производительности, и уже сравнивать с вендорской 2ух котроллерной СХД нельзя.
Так не одиночная же. Обычно берут 2ух контроллерную, а это аналог 2ух узлов в самодельном SAN'е.
Вот как раз если попытаться повторить один в один вендорскую СХД (например какую-нибудь OceanStor Dorado5000 V3) с близки показателями по iops, latency, доступности, то будет сопоставимо по цене (заоблочные цены из статьи не рассматриваем), но при этом может быть меньшая функциональность (тот же dedup мало где нормально работает, да еще чтобы без просадки по производительности).
В сравнении вендорских СХД и тех, которые можно построить самостоятельно на базе того же Supermicro, не все так однозначно.
Например, вендорская СХД: 2 контроллера, куча RAM кэша, рабочие dedup/compression, thin volumes, различные программные прослойки для удобства управления дисками, массивами и т.д.
Чтобы построить что-то хоть немного аналогичное: нужно 2x сервера c HBA и производительными CPU, шареный jbod, подключенный к головам по SAS, различная мелочевка для коммутации этого всего, ну и, собственно, SAS диски (SAS-SSD от любого вендора будут не дешевыми). По программной части будет что-нибудь типа: mdadm — lvm — iscsi_target. По итогу: нету RAM кэша (мы же не можем рисковать, с отдельным сервером может случиться что угодно), нету dedup/compression, с mdadm+lvm нельзя добиться такой гибкости и такого функционала, какой есть в вендорских СХД (пример). При этом по цене не факт, что получится дешевле, особенно вместе с SAS-SSD дисками.
Альтернативой может быть ceph, но его грамотная поддержка потребует больше ресурсов и более квалифицированный персонал чем первые 2 варианта. Желательно разбираться в кодовой базе ceph, возможно понадобится вносить правки, тестировать все это.
/sys/block/sdX/statполя read ticks, write ticks или в/proc/diskstatаналоничные по смыслу поля). Делим на количество io в еденицу времени и получаем честный средний latency (await).В случае с *_svctime цифра может не иметь ничего общего с реальным latency. Наример: за 1 секунду было сделано 5 параллельных r_io опреаций, каждая выполнялась 1 секунду. Реальный средний r_latency (и посчитанный исходя из 5ти секунд read ticks) — 1 секунда, r_svctime же будет 1/5 = 0.2 секунды.
Способов много можно придумать, у каждого будут свои плюсы и минусы в конкретной ситуации.
Откдуда взято предположение, что jenkins hash ipset'а будет производительние и экономичнее чем модифицированный LPC-trie для обработки одинакового количества ipv4 адресов/подсетей (неплохое описание и тесты, да и на хабре писали)? Т.е. если ядерная маршрутизация не справится, то с iptables+ipset+ip_rules лучше не будет. Другое дело, что надо смотреть версию ядра, раньше hash использовался для таблицы маршрутизации и некоторые оптимизации позже появились.
psс флагомf (-H). В варианте автора еще показывается, через что общаются между собой процессы, если общаются.И все же, если это не какая-то исключительная ситуация, лучше пока устанавливать python 2.x, как и сделал автор поста.
Из faq последней версии ansible:
И в документации поддержка python 3.x все еще помечена как technology preview feature.
-X.Сделать-то можно, но точной консистентности данных не получится. Можно, конечно, остановить все сервисы и сделать remount root'а в read only, но легче ребутнуться и сделать финальный rsync из live окружения и гарантировать консистентность. Ведь все равно сервисы будут недоступны и в первом варианте.
pvmove? Создается raid через тот же dm-raid и дальше только мониторится процесс синка с заданным интервалом. Мало того, процесс pvmove можно спокойно «прибивать» сразу после запуска, на синк это никак не повлияет (сам процесс синка можно будет мониторить, например, так:dmsetup status|grep mirror). Pvmove только меняет lvm метаданные, создает raid и по окончанию меняет метаданные снова и разваливает raid.systemctl enable fstrim.timer, для trim'а раз в неделю в рассматриваемом дистрибутиве).Если говорить о redhat-производных дистрибитивах, то можно на этапе загрузки добавить опции в commandline ядра:
inst.sshd inst.vnc inst.vncpassword=pass. Ssh, правда, будет беспарольный, и если сеть недоверенная, то после первого захода лучше установить пароль. Этот способ удобней, если используется не livecd, а какой-нибудь minimal/netinstall и не будет подготовленных конфигов для запуска ssh с помощью systemd/init сервиса + есть vnc, если хочется графики.Тут небольшая путаница. Новый диск (его раздел) добавляется в физичесий том, физический том в логическую группу томов (расширяется существующая), и затем логический том переносится внутри логической группы на другий физический носитель (физичесий том).
Можно и без
chroot, у grub2-install есть опция--boot-directory. В том числе актуально, если под рукой есть только x86 live, а препарируемая система — x86_64 и chrot'нуться не получится.Ну и как говорили выше, намного универсальней будет использовать rsync, например с опциями
--delete --numeric-ids -aHAXS(сохраняем все возможные атрибуты в неизменном виде), тогда мы не зависим от фс между которыми перенос. Если сервер выключен, то ничего exclud'ить не надо. А если нужно минимизировать время простоя, то обычно делают 3ой rsync (в live режиме с exclud'ами, еще раз, чтобы синхронизировать разницу, которая накопилась во время первого прогона и 3ий раз после выключения).