Pull to refresh
450
0
Алексей @SaveTheRbtz

SRE

Send message

Могу подтвердить данные в ролике по 198ому округу на основе данных блокчейна (абсолютное и относительное кол-во голосов Брюхановой и Хованской)

Данные брались из официального блокчейна: (+ ручное декодирование недостающих голосов)

SELECT datetime, ballot.decrypted_choice[1] as choice
FROM public.decrypted_ballots as ballot
JOIN public.transactions as trans_store
ON (ballot.store_tx_hash = trans_store.hash)
WHERE ballot.decrypted_choice[1] in (217404809,136749451) ORDER BY datetime

Поправка: меняешь байт (по битово перебирать нельзя ибо перезаписывать можно только по байтово.) Вероятность угадать байт 1/256 и того за (в среднем) 1024 попытки перебирается 8 байт.

Самое забавное, что за переход отвечали Олег из Подмосковья и Руслан из Екатеринбурга, а рядом держал свечку Питерский наркоман Алексей =)

Всё относительно просто: меняешь один бит в канарейке, если приложение упало то не угадал, приложение перефокнулось и пытаешься снова. И того на каждый бит у тебя 50/50 шанс — 8 байт так перебрать можно очень быстро.

Текущий план решить эту проблему с Envoy — кеширование + проксирование в S3 (или любой другой object storage). Оно проще:


  • с точки зрения поддержки. Не нужно поддерживать stateful сервис: серверов раздающих статику обычно несколько так что нужно мониторить что файлы на всех серверах есть и хеши совпадают.
  • с точки зрения разработки. У программистов появляется API для работы со статикой (S3 API или подобный), вместо сложной интеграции с системой деплоя для пуша новой версии статики по всем серверам.

Хотелось бы чуть больше информации по эксплуатации этой системы.


По структурной целостности:


  • Как бекапите метаданные Андрей Бородин рассказывал в лекции "Разгоняем бэкап". Было бы интересно услышать больше про то как эти бекапы верифицируются. В QnA секции прошлись по этому немного, но только с точки зрения физической структуры (checksum'ы и index'ы), а не логической — то что бекап действительно является репликой существующей базы и способен подключиться к кластеру как слейв.
  • Какие verifier'ы вы запускаете на данных, например, как вы проверяете что реплики не разошлись, что данные что были записаны всё ещё доступны и тд и тп? Shameless plug: у нас кажется верификаций больше чем кода самого приложения.

По доступности:


  • Что за система отвечает за замену умерающих/мёртвых машин. Особенно интересен случай мееедленно умирающей машины, который очень сложно отличить от перегрева шарда.
  • Как боритесь с горячими шардами по IOPS/QPS?

Ну и около-админские вещи: как вы безопасно деплоите код/ОС/прошивки/железо на кластер, как мониторите всю систему, итд итп

Весьма практическая статья, спасибо.


Я не фанат SQL, поэтому если бы я проектировал эту систему, то спрятал бы S3DB за API и сделал бы всю коммуникацию RPC-based (у нас внутри gRPC, у FB Thrift) ala services.
Meta бы делал на Zookeeper/etcd, чтобы Proxy могли подписываться на изменения "топологии". S3DB "сервис" бы в случае ошибки маршрутизации просто бы говорил, что proxy ошиблась и ей нужно получить новую таблицу у Meta. Что же использует S3DB для хранения не так важно, это может быть Postgres/MySQL/RocksDB/etc.


Ну и да, если бы это делалось в Dropbox, то полный S3 API мы бы наверное не поддерживали, а в замен сделали бы свой S3-подобный API. Описали бы протобафы, а код для клиентов под все языки сгенерился бы автоматом (aka codegen).


Disclaimer: в своё время я работал над Elliptics: делал из eblob LSM и писал первые версии dnet_recovery.

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


Двухшаговое удаление ещё упрощает написание verifier'ов которые следят за нарушениями соглашений "модели данных", например о том что данные которые были "удалены" в одной базе всё ещё имеют живые ссылки в какой-либо другой базе. У нас так регулярно находятся проблемы в процедуре подчистки базы от старых ревизий файлов, не потому что она бажная, а потому что мир вокруг неё меняется.


ПС. Вау! У кого-то серьёзный батхёрт на тему высшего образования. Ну и уровней абстракций походу тоже.

Спасибо, что проделали столь масштабную работу!


ПС. Забавно, что статья думалась на русском, писалась на английском, потом американский редаткор страдал, правя сложносочинённые конструкции, а теперь результат опять на "великом и могучем".
ППС. Вы пропустили последний абзац, но я так понимаю, это плата за перевод =)

Понимать смысл говорите умеет? А Тест Тьюринга^W^W Winograd Schema Challenge (WSC) оно уже проходит? =)


PS. ну или вот тут даже луше, чем на вики: http://commonsensereasoning.org/winograd.html

Не прошло и трёх лет, как ребята придумали как сделать адекватные Proof-of-Storage и Proof-of-Spacetime: https://filecoin.io/filecoin.pdf


Мы стали на один шаг ближе к миру, где майнеры ставят стороджа по всему миру, вместо того, чтобы жечь электричество впустую брутфорся sha256.

Ну, если совсем по чесноку, то не все =)


На больших нагрузках nginx может блокировать eventloop на:


  • Записи логов. В случае access_log'ов — может сильно помочь директива buffer=. Однако в идеале лучше писать логи напрямую в syslog.
  • Записи тел запросов и ответов на диск. Тут хорошо помогает костыль в виде aio threads. Однако, насколько я понимаю, он не работает для приёма файлов, только на отдачу.
    (Почему костыль? Потому что в идеале aio должно работать через нативный аснихронный интерфейс к файловой системе, а не эмулироваться через thread pool, но в *nix ОС с этим всё плохо).
  • В худшем случае, nginx начинает блокироваться на TLS хендшейках: если вы используете RSA 2048 это примерно 2мс на handshake. В новом OpenSSL 1.1.0 появилось асинхронное API, но в nginx оно если и попадёт, то не скоро. (Патчи по интернетам ходят, но до продакшна я бы их не допускал пока).
  • Были ещё сложные случаи со сжатием, когда люди пытаются максимально сжать статику (например, gzip 9 и brotli 11). в таких случаях сильно лучше статику pre-сжимать в офлайне и использовать gzip_static и brotli_static. Что делать если хочется по-максимуму сжимать динамку пока не понятно, но оно обычно того не стоит. (Можно, наверное, сжимать на backend'е(или маленьком sidecar-демоне), но это значит больше нельзя применять никакие body-filter'ы).
  • Image Filter'ы скорее всего тоже могут блокировать eventloop, но я, если честно, код не смотрел, ибо не использовал — все конторы в которых я работал писали простенькие backend'ы для "тяжёлых" манипуляций типа resize/recompress/crop/etc.

Проблема лишь в том, что маленький ssl_buffer_size добавляет измеримый CPU-overhead. И если есть желание оптимизировать один и тот же конфиг для пропускной способности и низкой задержки, то необходимо вручную выставлять нужный размер буферов для каждого server/location блока в зависимости от гистограммы размеров ответов.

Дамп сознания.
  • На CentOS/RHEL лучше тащить своё ядро из последних (3.16+, а то и 4.x, если есть лица способные чинить panic'и/регрессии)
  • При возможности ещё и собирать последние ixgbe/i40e от интела (ну или хотя бы README прочитать — он весьма полезен) и последний ethtool
  • Последняя версия set_irq_affinity.sh из того же комплекта — must have
  • Не забывайте, что 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 — важно, чтобы оно было выставленно в ноль
  • Flow Director может приводить к сильному реордеингу. Наступали на это в кеше в Facebook'а.
  • Не забываем играться со всей магией из ethtool -k (tso, lro,[rt]xcsum, etc) и почти всегда надо задирать ring buffer'а в ethtool -g
  • Обратите внимание на топологию PCIe и скорость: lspci -t -vvv (особо важно для 40G+)
  • Проверить, что ioatdma/DCA включено и работает
  • Всё что выходит за пределы 40G — надо переходить на Netmap/DPDK/etc
  • Jumboframes наружу конечно нельзя, но вот внутри сети лучше включить
  • Если у вас есть HTTPS, то всё становится сложнее, Netflix опять же похачил (FreeBSD'шное) ядро, чтобы то умело делать sendfile(2) с AES
  • Уже не совсем в тему оптимизации производительности, а скорее ускореения пользователей — стоит поиграться с TCP congestion алгоритмами (Netflix написали свой оптимизированый для видео и их склиентов: cc_netflix) — щас говорят ещё модно CDG (упаковать его в dkms и проверить на паре фронтэндов займёт пол дня)
  • Если бы у вас были интерактивные штуки, а не видео, то было бы интересно поиграться с buffer bloat (sch_fq, tsq, bql, etc).
  • В ту же степь: net.ipv4.tcp_slow_start_after_idle=0
  • В userspace (оптимизация webserver'а) можно быстро получить выхлоп от нового OpenSSL 1.0.2 и Haswell (там переписан TLS RSA handshake на AVX2)
  • Новый pcre с jit (или замена его на re2)
  • glibc malloc (почти ptmalloc) заменить на jemalloc
Начиная с 3.5 в ядре Linux появились uprobe'ы, то есть фактически аналог kprobe для userspace'а. Они тоже местами весьма полезны:
Пример использования uprobe с perf
# perf probe -x /bin/bash 'readline%return +0($retval):string'
Added new event:
  probe_bash:readline  (on readline%return in /bin/bash with +0($retval):string)

You can now use it in all perf tools, such as:

    perf record -e probe_bash:readline -aR sleep 1

# perf record -e probe_bash:readline -a
^C[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.259 MB perf.data (2 samples) ]

# perf script
 bash 26239 [003] 283194.152199: probe_bash:readline: (48db60 <- 41e876) arg1="ls -l"
 bash 26239 [003] 283195.016155: probe_bash:readline: (48db60 <- 41e876) arg1="date"
# perf probe --del probe_bash:readline
Removed event: probe_bash:readline


Из доступных рядовому юзеру кросс-платформенных open-source'ных torrent-клиентов сейчас есть, как минимум, transmission — при особом желаннии провайдеры/трекеры могут начать продвигать свои BEP'ы и контрибьютить код в апстрим.
Bitcoin в качестве proof-of-work использует количество правильно про-brute-force'иных бит sha256 хеша. То есть, жжошь CPU — получаешь деньги «из воздуха». Если придумать как делать proof-of-work на основе сремени хранения данных на диске, то можно построить экономическую систему, где новая валюта получаются путём генерации востребованного контента, а существующая получается через/тратится через скачивание/раздачу контента и аренду места/полосы у других участников сети под свои данные (тут можно замутить аукцион). Опять же, как описать всё это математически и защитить цифровыми подписями — отдельный вопрос

Фактически, всё вышеописанное, это ровно то как сейчас работают трекеры, где в качестве валюты используется «ratio» (которое отражает сколько раздач и как долго ты хранишь). Всё централизовано и в качестве регулятора валюты выстурает трекер. Разве, что в торренте нет способа пропросить кого-либо хранить и раздавать твои данные в обмен на свой ratio.
Отдельный вопрос как анонимизировать всё это. В bitcoin вся история транзакций публична, что может сильно усложнить дальнейшую «анонимизацию» пользователей такой bitcoin-style p2p системы.

В общем, дискуссия про то как скрестить p2p и bitcoin вполне потянет докторскую. Тема интересная, да.
В далёком 2007 году, когда мало кто мог представить, какая цензура будет грозить российскому интернету, мы в NNM-Club обсуждали альтернативы bittorrent'у:
Share & WinNY: японские p2p

Что самое интересное все три сети Winny, Share и Perfect Dark родом из японии, где шарить в сети аниме весьма распространённое и довольно опасное занятие.
Ещё в последнее время сильно набрал популярность Freenet.

Данные сети частично используют идеи из этого поста, частично из I2P/tor, частично из bittorrent. Но в любом случае все они сильно отличаются от того, что мы на данный момент имеем в мире торрент-трекеров. Думаю преминив некоторое кол-во усилий можно написать «прокси» из bittorrent в анонимные сети (например, freenet) и сделать его плагином к торрент-клиентам, чтобы то, что было скчано/роздано через bittorrent автоматом клалось и туда. Посути такой dual-stack получится (прям как во время перехода с IPv4 на IPv6). Я делал что-то подобное когда использовал Direct Connect и Bittorrent: то что у меня скачивалось rtorrent'ом автоматически шарилось в DC++.

Information

Rating
Does not participate
Location
Mountain View, California, США
Works in
Registered
Activity