Pull to refresh
4
0
Дрябжинский Сергей @SergeyD

User

Send message
Похоже на план цикла статей.
Серьезно, напишите все 6+.
Это же интересно!

Как-то так:


sync;
echo 3 > /proc/sys/vm/drop_caches
echo 1 > /proc/sys/kernel/sysrq
echo b > /proc/sysrq-trigger
Возможно что-то с route? Что показывает route -n на обоих серверах?
100% merlin-vrn

Уже заглючил и замочил свой же кластер. Хорошо конфиги в бекапах были.
При этом туннели работали.

К этому времени уже успели переключиться на туннели на GRE.
Так как openvpn вносил задержки, существенные для corosync (график чуть выше).

mobilesfinks, увы, единая точка отказа — сам proxmox.
Понятно.

Тогда меня ввел в заблуждение «громкий» заголовок статьи.
Ожидал большего. Или большого исследования.
Попробую немного прояснить претензии igordata

1. gzip

Насколько я помню, Zabbix не умеет запрашивать с веб-серверов страницы, используя сжатие.

Если сервер «далеко», и канал небыстрый — передача меньшего кол-ва данных может «ускорить» результаты.

И это зависит от настроек серверов.

2. ping

Если замеры велись с другого сервера, то хорошо бы учитывать время ответа сервера и пересылки кусочков (chunk) данных. Обычно можно смело отнимать 2*ping миллисекунд от результата.

Т.е. лучше замерять с соседнего сервера или ВМ (если ядерность позволяет).

3. Zabbix

Zabbix не скачивает js, css и прочую статику из кода html. Совсем. Просто скачивает по URL, смотрит код ответа, время ответа и т.д.

4. Конфиги

Их лучше выложить, чтобы другие люди смогли проверить, потестировать сами. И после этого конструктивно спорить.

5. Тестирование

Не хватает самой интересной части — как разные версии кушают память и как справляются с «типовыми» нагрузками.

Память можно померять и zabbix-ом, но очень ограниченно — процессы apache и fpm не будут висеть постоянно.

А вот «типовую» нагрузку, похожую на поведение пользователя с переходами по страницам, можно получить с помощью siege. Чтобы оценить работу php, нужно застравить его поработать, попользовать кеш на 100%, поработать с БД и т.д.
Пока нет, но производители браузеров уже пробуют внедрять запись аудио и видео в браузеры

Пока нашел только MediaRecorder от Mozilla.
Этим API можно «стримить» только в виде нарезок, как HLS/DASH, отправляя Blob постом на сервер, например.
Ну и хром, ослик и другие пауканы похоже будут делать свои велосипеды.

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

Это понятно. Весь вопрос в том, кто же этот посредник.
Насколько я понимаю, модуль для nginx используется только для обмена метаданными?
И, после «рукопожатия», клиенты обмениваются видео-данными уже напрямую или через TURN/STUN сервер?
Есть ли при этом возможность записывать видео/звук?
Туннели поднимаем, чтобы заработал кластер.
Кластер поднимаем, чтобы переносить контейнеры встроенными средствами Proxmox.
Что в этом удивительного?
Ну и в дополнение — частое кворумление приводит вот к такому ожирению у corosync:
график из zabbix
image

Нашел статью, в которой подробно всё описано. Только не про gretap, а GRE-туннель. Надо будет попробовать.
Увы, если адреса серверов в разных подсетях, то unicast не поможет. Вот, что говорят люди.

Information

Rating
Does not participate
Location
Зеленоград, Москва и Московская обл., Россия
Date of birth
Registered
Activity