Отличная статья, но на мой взгляд местами too opinionated :)
Ничего не имею против Werf, я люблю стандартизацию подходов и тулза у вас вышла отличная, но тем не менее выскажу немного критики по содержанию:
CI/CD у нас обычно несколько окружений (production, staging, development и т. д.). И конфигурация приложения может отличаться для разных окружений.
Технически Helm позволяет конфигурировать описанный chart параметрами, через которые передаются образы приложения и выбранное окружение. Однако конкретный путь — как это делать — не стандартизован. Пользователю Helm приходится решать это самому.
На счёт "не стандартизован" соглашусь, вариантов достичь желаемого достаточно много: можно передавать параметры через опции CLI или переменные окружения; можно пилить umbrela-чарты с оверрайдами для каждого энвайромента, но считаю что подход с использованием нескольких values файлов наиболее стандартным и популярным:
-f base.yaml -f stage.yaml
-f base.yaml -f prod.yaml
Кстати, аналогичным образом можно передавать и секреты.
Если я правильно понял, werf позволяет реализовать тот же паттерн, но в виду упомянутого вами гитерминизма, по прежнему, не является правильным. К слову, тот же Helmfile позволяет указать набор параметров для хельма в зависимости от конкретного энвайромента.
Таким образом у меня по прежнему возникает вопрос: каким образом в werf правильно хранить и передавать параметры для разных энвайроментов? :)
werf должна поддерживать GitOps-подход
GitOps в общем виде — это подход, при котором для развертывания приложений в Kubernetes используется единственный источник правды — Git-репозиторий. Через декларативные действия в Git вы управляете реальным состоянием инфраструктуры, запущенной в Kubernetes. Этот паттерн «из коробки» работает в werf.
У нас есть собственный взгляд на то, как должен быть реализован GitOps для CI/CD (уже упомянутый Giterminism). GitOps в werf поддерживает не только хранение Kubernetes-манифестов в Git, но и версионирование собираемых образов, связанное с Git. Откат до предыдущей версии приложения выполняется без сборки выкатывавшихся ранее образов (при условии, что версия учитывается политиками очистки). Другие существующие реализации GitOps не дают этой гарантии.
Можно долго ходить вокруг да около GitOps (огромное "спасибо" Weaveworks за то что придумали такой неоднозначный термин). Хранение правды в Git да, но всё-таки оно немного не про то.
Использование GitOps подразумевает наличие контроллера или GitOps-оператора (называйте как хотите), который делает непрерывный синк состояния Git-репозитория с Kubernetes-кластером.
По сути — это такой же reconciling loop, по аналогии с тем как контроллеры Kubernetes создают нижестоящие ресурсы. Например Deployment генерирует ReplicaSet, ReplicaSet генерирует Pods. Таким же образом должен работать и GitOps-оператор, отрендерив код описанного приложения в Git-репозитории, он должен непрерывно перекладывать его в Kubernetes.
Оба решения Helm и Werf не обладают данной характеристикой. Однако иметь контроллер Werf для Flux2, думаю, было бы весьма здорово.
Для организации GitOps, в том понимании в котором он изначально задумывался, таких решения сейчас два: ArgoCD и FluxCD. Второй более нативен к хельму, так как непосредственно использует его для деплоя в кластер.
Забавен тот факт, что применение GitOps может быть вообще не завязано на использование Git. Вышеупомянутые тулзы могут следить и работать также с Helm-registry и даже S3-бакетами.
У нас есть собственный взгляд на то, как должен быть реализован GitOps для CI/CD (уже упомянутый Giterminism). GitOps в werf поддерживает не только хранение Kubernetes-манифестов в Git, но и версионирование собираемых образов, связанное с Git. Откат до предыдущей версии приложения выполняется без сборки выкатывавшихся ранее образов (при условии, что версия учитывается политиками очистки). Другие существующие реализации GitOps не дают этой гарантии.
Здесь стоит упомянуть про kbld и kapp и другие утилиты от Caravel, которые делают примерно тоже самое что и Werf, но без жёсткой привязки к конкретному стеку.
И Gitkube, решения, которое может выступать в качестве гейтвея для деплоя с помощью простого git push, оно также умеет собирать образы и подставлять дайджест в темплейты.
Так как оно представляет своего рода гейтвей Git-to-Kubernetes, оно в принципе не позволяет запушить неисправный коммит в кластер. Таким образом, скрепя зубами, его всё таки можно назвать push-based GitOps-решением, однако оно не развивается уже как 3 года и я не советовал бы его использовать.
Моё мнение, что текущий вектор развития Werf, если вы держите курс на GitOps, должен основываться на изложенных выше идеях. При этом вам не потребуется существенно изменять функционал и логику работы Werf. Наоборот, вам просто нужно дополнить её соответствующим контроллером.
Рестартить вам нужно будет и те поды, у которых дефолтный токен, иначе будет много 404 у API сервера да и просто дефолтный SA может использоваться. Если же поду не нужен доступ к API серверу, тогда нужно отключить автомонтирование дефолтного токена automountServiceAccountToken: false.
Если вы потеряли только приватный ключ для подписи SA токенов, а сертификат у вас все еще есть, то можно сгенерить новую пару, сконфигурить новый приватный ключ controller-manager, добавить новый сертификат и оставить старый API серверу. Тогда ничего удалять не надо и ничего рестартить не надо.
Пара сертификат-ключ который используется для SA один и тот же на всех инстансах API и controller-manager. Потому если потеряли на одном инстансе, то проще скопировать с других нод, тогда совсем ничего делать не надо.
С pv можно ограничить скорость создания дампа (если чтение с базы быстрее скорости дисков и iowait уходит в 100%, в результате чего создание дампа мешает другим сервисам работать с диском) можно добавить: pv -L 10m, где 10m — ограничение в 10 Мб/с.
сейчас как раз занимаюсь люстрой.
Во-первых Вы не указали важный факт — у люстры НЕТ фейловера и репликации. Т.е. если Вы хотите у себя отказоустойчивость, то потребуется либо шаред сторадж + heartbeat, либо drbd + heartbeat. Это раз.
Два — Ваша статья претендует на хауту, но в ней нет важных моментов. Например в продакшене требуется отключить дебаг на серверах и клиенах: echo 0 > /proc/sys/lnet/debug. С дебагом работает значительно медленнее.
Так же не сказано, что по дефолту файлы страйпятся из принципа — один файл->одна нода. Это можно и нужно изменять. Но на массивах с большими (> 1M) файлами. Почитать об этом можно вот тут: blogs.sun.com/atulvid/entry/improving_performance_of_small_files
Три, это вопрос уже тем, кто использует люстру в продакшене. Как быть с мелкими файлами? У меня просто чудовищно низкая скорость записи/чтения мелких файлов.
Если к нашему серверу придёт запрос на первый интерфейс (188), то ответ на него всё равно пойдёт по нижнему. Если у маршрутизатора/провайдера есть хотя бы минимальная защита от подделки адресов, то ответ просто дропнут, как невалидный (с точки зрения 241.241.241.1 ему прислали из сети 241.241.241.0/24 пакет с src 188.188.188.188, чего, очевидно, быть не должно).
Не совсем.
По умолчанию, наверное, в большинстве дистрибутивов (Ubuntu, Fedora, ArchLinux) уже стоит net.ipv4.conf.*.rp_filter=1. Знаю только Debian, где по умолчанию 0.
Если этот параметр установлен в значение 1, приложение, получающее входящий пакет, пришедший, скажем, на интерфейс с IP 188, вообще не получит его, его отбросит ядро как Martian packet.
Такие пакеты можно логировать, что очень удобно:
# sysctl net.ipv4.conf.*.log_martians=1
Если же rp_filter отключен, то в Linux ответ действительно пойдет с неправильным IP через неправильный интерфейс, независимо от протокола, и, с большой вероятностью, отбросится провайдерскими маршрутизаторами. А вот в Windows и OS X все интересней: в Windows, при использовании TCP, никакой дополнительной настройки source routing не требуется — ответ на пакет, пришедший на определенный интерфейс, пойдет через этот же интерфейс и с правильным IP, аналогичная ситуация для TCP наблюдается и в OS X.
А вот с UDP все интересней: как в Windows, так и в OS X, ответ на пакет, пришедший с одного интерфейса, уйдет через другой интерфейс с правильным IP другого интерфейса!
Надеюсь, в середине недели расскажу об этом более подробно отдельной статьей — такая, казалось бы, очевидная вещь, с которой сталкивался любой, кто настраивал Multi WAN и Multihoming, может использоваться для деанонимизации пользователей VPN.
Нашел.
PROMPT_COMMAND='history -a; history -n'
Нажатие Enter в консоли обновляет историю. По сути история будет обновляться после выполнения каждой команды. Возможно это не очень удобно.
PS Тихо сам с собой веду беседу, спасибо за внимание…
Привожу часть моего .bashrc.
Последние строчки позволяют сохранять историю хоть в 100, одновременно открытых терминалах.
#Чтобы одинаковые команды не сохранялись в истории, добавьте строчку:
HISTCONTROL=ignoredups
#Не добавлять запись в историю команд, если команда начинается с пробела:
HISTCONTROL=ignorespace
#стираются все повторения, в том числе идущие не подряд, но в разной последовательности. (например, после cd..ls..cd..ls останется cd и ls)
HISTCONTROL=erasedups
# Чтобы история команд сохранялась сразу после ввода (а не во время закрытия терминала)
shopt -s histappend
PROMPT_COMMAND='history -a'
Согласен, но поверх этого можно развернуть какой-нибудь ip-туннель через tcp, он и будет гарантировать доставку каждого пакета.
У нас уже TCP, зачем нам пересылать TCP внутри TCP? Дело не в гарантии доставки, а в скорости работы. Существующие распространенные алгоритмы congestion control плохо работают и со скачущим пингом, и вообще с разными каналами. У вас TCP-окно будет подстраиваться под самый плохой канал (и в смысле скорости, и в смысле задержки), и быстрый канал будет утилизироваться на малый процент.
Хорошего unix-way-решения в принципе не может быть, оно будет всегда плохое. Корректных решений два:
1. MPTCP с локальным терминированием TCP.
2. Свой ARQ-протокол с инкапсуляцией в UDP и локальным терминированием TCP.
Вы о выше упомянутых 20гб? Это очень завышенная оценка, FreeBSD даёт оценку в ~ 5 гб на 1тб. Тут прекрасно описан метод работы DDT, там же приводятся конкретные цифры — 320 байт на каждую запись (уникальный блок).
Вообще есть прекрасная возможность заранее получить точные цифры — у zdb есть возможность имитации дедупликации:
zdb -S название_пула
На выходе будет Total allocated blocks, перемножив его на 320 байт получим требуемое количество ОЗУ. Также там приводится коэффициент дедупликации.
Вот симуляция для моего пула (бекапы, /home, /, немного виртуалок, одним словом дедуплицировать особо нечего):
На мои 800гб корневого пула, вообще не оптимизированного для dedup (а также 230гб бекапов с размером блока 1МБ) он дал всего лишь коэффициент 1.18, при этом на DDT потребуется 10.8М*320=3456мб ОЗУ. Оракл не рекомендует включать дедупликацию при коэффициенте меньше 2, я с ними полностью согласен.
Дедупликация — это прекрасно, но практически бесплатное lz4 сжатие (а для большинства HDD оно только ускоряет) в случае неповторяющихся данных намного целесообразнее.
флешки обычные на 16/32 GB, usb 3.0, но стоят в портах 2.0. Я, правда, выбирал чтобы не самые тормознутые, но без фанатизма, по 8-10 евро брал примерно. Proxmox довольно мало обращается к диску сам по себе, роутер тоже, даже обычный убунту-сервер, сам по себе большой производительности от диска не требует. А какие у Вас были проблемы? Что именно тормозило?
Я устанавливал прямо обычным установщиком Proxmox'a, с флешки на флешку, как тут описано. Обратите внимание на rootdelay. Дополнительно настраивал что бы меньше обращений к диску было, как советуют во всяких («устаревших») мануалах по установке линукса на SSD, но не знаю, какую роль эти настройки играют, наверное, и без них ок. Главное чтобы свопа на флешке не было, наверное.
Вот мои настройки: > systemctl enable tmp.mount
2.b) Ну они и так делят ресурсы и используют один и тот же пул zfs. У меня настроено и через NFS и через ZFS-over-iSCSI, оба варианта поддерживаются в Proxmox. Мне кажется, лучше максимально разделить службы по контейнерам/вм в данном случае. С производительностью, наверное, сложнее, но люди же используют SAN и добиваются очень большой производительности, так что, наверное, при желании, можно и это настроить.
Простите, Enter сорвался :). Дополняю… а редактировать нет возможности.
Если у вас такой громкий заголовок статье, то почему нет параметров для оптимизации, а так же тесты и графики до и после?
Ну начнем по вашей же статье :)
Для тех, кто не в курсе: ceph сначала пишет данные на журнал, а через какое-то время переносит их на медленный OSD.
Вы очень сильно ошибаетесь, самое простое сравните количество чтение и записи на дисках с журналами.
какой размер журнала указать и какой параметр filestore max sync interval выбрать.
10Gb, значение filestore max sync interval по умолчанию подходит в 99.9% случаях.
Один большой пул ведет к проблемам с удобством управления и апгрейдом. Как апгрейд связан с размером пула?
Абсолютно ни как не связан.
поэтому есть смысл развернуть новый небольшой рядом, отреплецировать данные в новый пул и переключить.
Если понимать с вопроса «развернуть новый кластер?»
Не рассказывайте пожалуйста про rbd-mirror никому, т.к для прода он не готов и между разными версиями кластеров, в данный момент, в принципе не работает.
Если понимать с вопроса «развернуть новый пул?»
Риски от этого не изменяться, т.к. сервера с MON нужно обновлять до OSD. Отсюда следует, что изменение CRUSH-карты и распределение пула по определенным OSD нодам, ни чего полезного не даст.
с одним JBOD и 30-ю дисками
МММ? ;)
между нодами CEPH 10гбит/сек обязательно
C 30 дисками и 40Гбит/сек будет недостаточно, если использовать значения по умолчанию.
CEPH имеется проверка целостности данных — так называемые scrub и deep scrub.
Все очень хорошо крутится с параметрами:
«osd_scrub_sleep»: «0.5», можно увеличивать
«osd_disk_thread_ioprio_class»: «idle»,
«osd_scrub_load_threshold»: «1»,
«osd_disk_thread_ioprio_priority»: «7»
С использованием cfq scheduler на хостах с OSD.
Ограничьте скорость ребаланса параметрами osd_recovery_op_priority и osd_client_op_priority. Вполне можно пережить днём медленный ребаланс
Уверен на 146%, что не переживете, если бы вы хорошо протестировали, вы бы это поняли.
переживете с помощью:
«osd_recovery_delay_start»: ">0",
«osd_max_backfills»: «1»,
«osd_recovery_threads»: «1»,
«osd_recovery_max_active»: «1»,
Не заполняйте кластер под завязку
то используйте reweight-by-utilization.
Вы сами себе противоречите, т.к. reweight-by-utilization выставляет «высоты» OSD, количество данных в кластере от этого не поменяется.
интересен мониторинг вывода ceph osd perf.
Из своего опыта могу смело сказать, что лучше анализировать через сокеты, более подробно: ceph --admin-daemon /var/run/ceph/ceph-osd.N.asok perf dump
Видели ООМ на ОСД. Просто пришёл ООМ, убил ОСД
Местами CEPH очень прожорлив по swap. Возможно надо править настройки swappiness.
Смотрим в сторону sysctl.conf: vm.min_free_kbytes = 1024000 я думаю, что решит вашу проблему.
FIO с параметром engine=rbd может врать.
Говорит правду, просто нужно учитывать что на клиенте по умолчанию: rbd_cache = true
Спасибо за ваш комментарий, Алексей.
Ради одного вашего комментария стоило писать эту статью.
Отвечу по пунктам:
Новое ядро пробовали пока только на видео раздаче, выигрыша не получили, но это скорее связано с (пока) неопределённой проблемой высокого softirq. Тоже самое с TCP congestion алгоритмами и tcp_slow_start_after_idle=0.
В стоковом ядре драйвер довольно новый, хоть и отличается от out-of-tree. Тем не менее мы их тоже тестили в рамках борьбы с softirq и тоже не помогло.
Вижу, что вы в set_irq_affinity учитываете NUMA и конфигурите XPS заодно — это круто. Мы используем модифицированный set_irq_affinity, который настраивает все очереди всех поднятых интерфейсов сразу + все прерывания дисковых контроллеров LSI и распределяем по очереди на все ядра по кругу. Но не учитываем NUMA. Что касается XPS, то на ixgbe и mlx4 он конфигурится автоматом. Надеюсь впилим и NUMA со временем.
Адаптивную модерацию мы выключаем (на i40e, например), т.к. она заботится о latency, а нам нужен был throughput.
NUMA лучше не интерливить, трудно не согласиться :) Пока приложение не готово, но мы работаем в этом направлении. А вы делали какие-то сравнительные тесты по NUMA — какой выигрыш на какой-нибудь активной раздаче?
zone_reclaim_mode умышленно не трогал.
Про OOO в Flow Director тоже читал и собираюсь упомянуть на Highload++, а то сам Intel про это как-то не упоминает.
Ринг буферы задраны и оффлоадинги включены. На самом деле, конечно, в статье далеко не все использованые оптимизации упомянуты, только то что было новым для нас.
На скорость PCIe уже наталкивались, теперь тщательно проверяем.
Для Netmap/DPDK надо писать свой TCP stack. Для mTCP перепиливать приложение. Fastsocket ещё не пробовали, но планируем. OpenOnload только с Solarflare, которого у нас нет. Было бы интересно узнать про success story использования user-space tcp с какими-то Java HTTP серверами (вроде lighttpd в который впилили mTCP сами разработчики mTCP).
Jumboframes тоже есть в планах.
Malloc менаем на tcmalloc.
Ещё раз спасибо за прекрасную подборку заклинаний! :)
Не забывайте, что irq affinity можно навешивать не только на сетевухи, но и на storage девайсы
Новые сетевухи умеют `adaptive-rx`/`adaptive-tx`, совсем новые `rx-usecs-high`
NUMA лучше не interleave'ить, а использовать по назначению. Запустите N инстансов приложения. Каждое на своей ноде. Каждой свой CPU и память, а так же сетевуху (NUMA ноду для irq affinity через можно определить от /sys/class/net/eth*/device/numa_node) и свой набор IP'шников. Далее на вышестоящем балансере (я так пологаю IPVS) считать каждую NUMA-ноду за отдельный хост
Для файлсерверов очень опасна/proc/sys/vm/zone_reclaim_mode — важно, чтобы оно было выставленно в ноль
Уже не совсем в тему оптимизации производительности, а скорее ускореения пользователей — стоит поиграться с TCP congestion алгоритмами (Netflix написали свой оптимизированый для видео и их склиентов: cc_netflix) — щас говорят ещё модно CDG (упаковать его в dkms и проверить на паре фронтэндов займёт пол дня)
Если бы у вас были интерактивные штуки, а не видео, то было бы интересно поиграться с buffer bloat (sch_fq, tsq, bql, etc).
LVM/Linear RAID пришлось бы накатывать сверху, с потерей данных дисков, да и делалось это, как я предполагаю, для другого.
Я использую aufs3, он ядерный и работает быстро. Объединяю 5 дисков своей файлопомойки, с балансировкой записи на тот диск, где места больше всего. У каждого диска одинаковая структура директорий, и преимущества такого подхода для файлопомойки очевидны:
Потеря только части данных (фильмов, мультиков, музыки) при выходе одного диска из строя. Причем часто так случается, что директория исчезает не вся, а в ней пропадает только часть, например, часть эпизодов сериала. Так как это файлопомойка, перекачать сериал не составляет проблемы.
Возможность работы только с частью подключенных дисков
Возможность работы вообще без aufs и его настройки
А минус для меня всего один — не такая высокая скорость работы, как была бы в Raid 0.
Отличная статья, но на мой взгляд местами too opinionated :)
Ничего не имею против Werf, я люблю стандартизацию подходов и тулза у вас вышла отличная, но тем не менее выскажу немного критики по содержанию:
На счёт "не стандартизован" соглашусь, вариантов достичь желаемого достаточно много: можно передавать параметры через опции CLI или переменные окружения; можно пилить umbrela-чарты с оверрайдами для каждого энвайромента, но считаю что подход с использованием нескольких values файлов наиболее стандартным и популярным:
Кстати, аналогичным образом можно передавать и секреты.
Если я правильно понял, werf позволяет реализовать тот же паттерн, но в виду упомянутого вами гитерминизма, по прежнему, не является правильным. К слову, тот же Helmfile позволяет указать набор параметров для хельма в зависимости от конкретного энвайромента.
Таким образом у меня по прежнему возникает вопрос: каким образом в werf правильно хранить и передавать параметры для разных энвайроментов? :)
Можно долго ходить вокруг да около GitOps (огромное "спасибо" Weaveworks за то что придумали такой неоднозначный термин). Хранение правды в Git да, но всё-таки оно немного не про то.
Использование GitOps подразумевает наличие контроллера или GitOps-оператора (называйте как хотите), который делает непрерывный синк состояния Git-репозитория с Kubernetes-кластером.
По сути — это такой же reconciling loop, по аналогии с тем как контроллеры Kubernetes создают нижестоящие ресурсы. Например Deployment генерирует ReplicaSet, ReplicaSet генерирует Pods. Таким же образом должен работать и GitOps-оператор, отрендерив код описанного приложения в Git-репозитории, он должен непрерывно перекладывать его в Kubernetes.
Оба решения Helm и Werf не обладают данной характеристикой. Однако иметь контроллер Werf для Flux2, думаю, было бы весьма здорово.
Для организации GitOps, в том понимании в котором он изначально задумывался, таких решения сейчас два: ArgoCD и FluxCD. Второй более нативен к хельму, так как непосредственно использует его для деплоя в кластер.
Забавен тот факт, что применение GitOps может быть вообще не завязано на использование Git. Вышеупомянутые тулзы могут следить и работать также с Helm-registry и даже S3-бакетами.
Здесь стоит упомянуть про kbld и kapp и другие утилиты от Caravel, которые делают примерно тоже самое что и Werf, но без жёсткой привязки к конкретному стеку.
И Gitkube, решения, которое может выступать в качестве гейтвея для деплоя с помощью простого
git push
, оно также умеет собирать образы и подставлять дайджест в темплейты.Так как оно представляет своего рода гейтвей Git-to-Kubernetes, оно в принципе не позволяет запушить неисправный коммит в кластер. Таким образом, скрепя зубами, его всё таки можно назвать push-based GitOps-решением, однако оно не развивается уже как 3 года и я не советовал бы его использовать.
Моё мнение, что текущий вектор развития Werf, если вы держите курс на GitOps, должен основываться на изложенных выше идеях. При этом вам не потребуется существенно изменять функционал и логику работы Werf. Наоборот, вам просто нужно дополнить её соответствующим контроллером.
На счет токенов сервис аккаунтов:
automountServiceAccountToken: false
.Тоже использую Percona, но с базой в <10 Гб. Пользуюсь дампом в sql-файл. Чтобы снять бекап без блокировки таблиц пользуюсь такими ключами:
В многоточиях описания разных состояний, бекап файловой структуры, архивация и отправка на S3.
Без показа текущего состояния и метки времени:
С
pv
можно ограничить скорость создания дампа (если чтение с базы быстрее скорости дисков и iowait уходит в 100%, в результате чего создание дампа мешает другим сервисам работать с диском) можно добавить:pv -L 10m
, где 10m — ограничение в 10 Мб/с.Во-первых Вы не указали важный факт — у люстры НЕТ фейловера и репликации. Т.е. если Вы хотите у себя отказоустойчивость, то потребуется либо шаред сторадж + heartbeat, либо drbd + heartbeat. Это раз.
Два — Ваша статья претендует на хауту, но в ней нет важных моментов. Например в продакшене требуется отключить дебаг на серверах и клиенах: echo 0 > /proc/sys/lnet/debug. С дебагом работает значительно медленнее.
Так же не сказано, что по дефолту файлы страйпятся из принципа — один файл->одна нода. Это можно и нужно изменять. Но на массивах с большими (> 1M) файлами. Почитать об этом можно вот тут: blogs.sun.com/atulvid/entry/improving_performance_of_small_files
Три, это вопрос уже тем, кто использует люстру в продакшене. Как быть с мелкими файлами? У меня просто чудовищно низкая скорость записи/чтения мелких файлов.
www.pimusicbox.com
volumio.org
www.runeaudio.com
moodeaudio.org
По умолчанию, наверное, в большинстве дистрибутивов (Ubuntu, Fedora, ArchLinux) уже стоит net.ipv4.conf.*.rp_filter=1. Знаю только Debian, где по умолчанию 0.
Если этот параметр установлен в значение 1, приложение, получающее входящий пакет, пришедший, скажем, на интерфейс с IP 188, вообще не получит его, его отбросит ядро как Martian packet.
Такие пакеты можно логировать, что очень удобно:
Если же rp_filter отключен, то в Linux ответ действительно пойдет с неправильным IP через неправильный интерфейс, независимо от протокола, и, с большой вероятностью, отбросится провайдерскими маршрутизаторами. А вот в Windows и OS X все интересней: в Windows, при использовании TCP, никакой дополнительной настройки source routing не требуется — ответ на пакет, пришедший на определенный интерфейс, пойдет через этот же интерфейс и с правильным IP, аналогичная ситуация для TCP наблюдается и в OS X.
А вот с UDP все интересней: как в Windows, так и в OS X, ответ на пакет, пришедший с одного интерфейса, уйдет через другой интерфейс с правильным IP другого интерфейса!
Надеюсь, в середине недели расскажу об этом более подробно отдельной статьей — такая, казалось бы, очевидная вещь, с которой сталкивался любой, кто настраивал Multi WAN и Multihoming, может использоваться для деанонимизации пользователей VPN.
PROMPT_COMMAND='history -a; history -n'
Нажатие Enter в консоли обновляет историю. По сути история будет обновляться после выполнения каждой команды. Возможно это не очень удобно.
PS Тихо сам с собой веду беседу, спасибо за внимание…
Последние строчки позволяют сохранять историю хоть в 100, одновременно открытых терминалах.
#Чтобы одинаковые команды не сохранялись в истории, добавьте строчку:
HISTCONTROL=ignoredups
#Не добавлять запись в историю команд, если команда начинается с пробела:
HISTCONTROL=ignorespace
#стираются все повторения, в том числе идущие не подряд, но в разной последовательности. (например, после cd..ls..cd..ls останется cd и ls)
HISTCONTROL=erasedups
# Чтобы история команд сохранялась сразу после ввода (а не во время закрытия терминала)
shopt -s histappend
PROMPT_COMMAND='history -a'
Хорошего unix-way-решения в принципе не может быть, оно будет всегда плохое. Корректных решений два:
1. MPTCP с локальным терминированием TCP.
2. Свой ARQ-протокол с инкапсуляцией в UDP и локальным терминированием TCP.
В часности посмотрите на
overlayroot
.Он просто устанавливается и как правило не требует лишних телодвижений:
Всего несколько команд и вы уже имеете систему в памяти:
На случай если нужно внести какие-то изменения:
Вы о выше упомянутых 20гб? Это очень завышенная оценка, FreeBSD даёт оценку в ~ 5 гб на 1тб.
Тут прекрасно описан метод работы DDT, там же приводятся конкретные цифры — 320 байт на каждую запись (уникальный блок).
Вообще есть прекрасная возможность заранее получить точные цифры — у zdb есть возможность имитации дедупликации:
На выходе будет Total allocated blocks, перемножив его на 320 байт получим требуемое количество ОЗУ. Также там приводится коэффициент дедупликации.
Вот симуляция для моего пула (бекапы, /home, /, немного виртуалок, одним словом дедуплицировать особо нечего):
На мои 800гб корневого пула, вообще не оптимизированного для dedup (а также 230гб бекапов с размером блока 1МБ) он дал всего лишь коэффициент 1.18, при этом на DDT потребуется 10.8М*320=3456мб ОЗУ. Оракл не рекомендует включать дедупликацию при коэффициенте меньше 2, я с ними полностью согласен.
Дедупликация — это прекрасно, но практически бесплатное lz4 сжатие (а для большинства HDD оно только ускоряет) в случае неповторяющихся данных намного целесообразнее.
Полезная ссылка.
Я устанавливал прямо обычным установщиком Proxmox'a, с флешки на флешку, как тут описано. Обратите внимание на
rootdelay
. Дополнительно настраивал что бы меньше обращений к диску было, как советуют во всяких («устаревших») мануалах по установке линукса на SSD, но не знаю, какую роль эти настройки играют, наверное, и без них ок. Главное чтобы свопа на флешке не было, наверное.Вот мои настройки:
> systemctl enable tmp.mount
> cat /etc/fstab
/dev/pve/root / ext4 commit=120,noatime,nodiratime,errors=remount-ro 0 1
UUID=219E-7546 /boot/efi vfat defaults 0 1
#/dev/pve/swap none swap sw 0 0
proc /proc proc defaults 0 0
> tail -n3 /etc/default/tmpfs
RAMTMP=yes
RAMRUN=yes
RAMLOCK=yes
2.b) Ну они и так делят ресурсы и используют один и тот же пул zfs. У меня настроено и через NFS и через ZFS-over-iSCSI, оба варианта поддерживаются в Proxmox. Мне кажется, лучше максимально разделить службы по контейнерам/вм в данном случае. С производительностью, наверное, сложнее, но люди же используют SAN и добиваются очень большой производительности, так что, наверное, при желании, можно и это настроить.
Медиум не так уж и плох. Часть статей оттуда переводятся на хабр.
Если у вас такой громкий заголовок статье, то почему нет параметров для оптимизации, а так же тесты и графики до и после?
Ну начнем по вашей же статье :)
Вы очень сильно ошибаетесь, самое простое сравните количество чтение и записи на дисках с журналами.
10Gb, значение filestore max sync interval по умолчанию подходит в 99.9% случаях.
Абсолютно ни как не связан.
Если понимать с вопроса «развернуть новый кластер?»
Не рассказывайте пожалуйста про rbd-mirror никому, т.к для прода он не готов и между разными версиями кластеров, в данный момент, в принципе не работает.
Если понимать с вопроса «развернуть новый пул?»
Риски от этого не изменяться, т.к. сервера с MON нужно обновлять до OSD. Отсюда следует, что изменение CRUSH-карты и распределение пула по определенным OSD нодам, ни чего полезного не даст.
МММ? ;)
C 30 дисками и 40Гбит/сек будет недостаточно, если использовать значения по умолчанию.
Все очень хорошо крутится с параметрами:
«osd_scrub_sleep»: «0.5», можно увеличивать
«osd_disk_thread_ioprio_class»: «idle»,
«osd_scrub_load_threshold»: «1»,
«osd_disk_thread_ioprio_priority»: «7»
С использованием cfq scheduler на хостах с OSD.
Уверен на 146%, что не переживете, если бы вы хорошо протестировали, вы бы это поняли.
переживете с помощью:
«osd_recovery_delay_start»: ">0",
«osd_max_backfills»: «1»,
«osd_recovery_threads»: «1»,
«osd_recovery_max_active»: «1»,
Вы сами себе противоречите, т.к. reweight-by-utilization выставляет «высоты» OSD, количество данных в кластере от этого не поменяется.
Из своего опыта могу смело сказать, что лучше анализировать через сокеты, более подробно: ceph --admin-daemon /var/run/ceph/ceph-osd.N.asok perf dump
Смотрим в сторону sysctl.conf: vm.min_free_kbytes = 1024000 я думаю, что решит вашу проблему.
Говорит правду, просто нужно учитывать что на клиенте по умолчанию: rbd_cache = true
Ради одного вашего комментария стоило писать эту статью.
Отвечу по пунктам:
Ещё раз спасибо за прекрасную подборку заклинаний! :)
/sys/class/net/eth*/device/numa_node
) и свой набор IP'шников. Далее на вышестоящем балансере (я так пологаю IPVS) считать каждую NUMA-ноду за отдельный хост/proc/sys/vm/zone_reclaim_mode
— важно, чтобы оно было выставленно в нольethtool -k
(tso, lro,[rt]xcsum, etc) и почти всегда надо задирать ring buffer'а вethtool -g
lspci -t -vvv
(особо важно для 40G+)cc_netflix
) — щас говорят ещё модно CDG (упаковать его в dkms и проверить на паре фронтэндов займёт пол дня)Я использую aufs3, он ядерный и работает быстро. Объединяю 5 дисков своей файлопомойки, с балансировкой записи на тот диск, где места больше всего. У каждого диска одинаковая структура директорий, и преимущества такого подхода для файлопомойки очевидны:
А минус для меня всего один — не такая высокая скорость работы, как была бы в Raid 0.
cc: mikes
Есть еще одно классное решение:
Можно хранить свои
dotfiles
вgit
, каждый конфиг в отдельной папочке.А
stow
позволяет устанавливать нужные как пакеты.и у вас последний конфиг для vim'а
(подробнее)