Как определить, когда ключ энтропии перегружен?
У меня есть несколько энтропийных ключей с egd перед ними, а затем вся нагрузка уравновешена haproxy. Затем у меня есть много клиентских машин, использующих IP-адрес службы haproxy в качестве источника энтропии в сети. Я понятия не имею, сколько энтропии они запрашивают.
Ключи энтропии могут давать ограниченное количество пригодной для использования энтропии. Спецификации говорят о минимальной скорости около 30 килобит / сек. Насколько я вижу, у ключа энтропии нет способа узнать, сколько его запрашивают. Протокол EGD кажется довольно сложным, чтобы найти эту информацию. Клиенты могут запросить переменное количество энтропии, и они могут не получить ту же сумму.
Кто-нибудь нашел простой способ измерить, сколько запрашивается от ключа энтропии?
Было бы полезно знать, чтобы иметь возможность планировать, когда требуются дополнительные ключи, и выявлять клиентов haywire.
3 ответа
Единственные две вещи, которые приходят на ум, - это попытаться измерить время отклика вашего сервера энтропии (должно быть значительное увеличение задержки, если он не успевает) или объединение в пул /proc/sys/kernel/random/entropy_avail
и контролировать, сколько энтропии у вас есть (я предполагаю, что egd
использует /dev/random
а не аппаратное обеспечение напрямую).
Похоже, исходный архив для ekeyd
имеет плагин munin для предоставления статистики ekey.
Даже если вы не используете munin, я думаю, можно было бы экстраполировать сценарий на что-то, пригодное для вашей инфраструктуры.
Я думаю, что мы оба знаем авторов устройства и программного обеспечения, поэтому, возможно, стоит подтолкнуть их.:-)
Пытаться:
dd if=/dev/random of=/dev/null bs=1K count=1M
Когда это закончится, dd
сообщит о пропускной способности чтения, так что вы будете знать количество предоставленной энтропии. Вы можете запустить его на сервере (отсоединенном от клиентов) для измерения производства энтропии, а на клиентах - для определения того, сколько они получают.
Убивая бег dd
процесс с SIGUSR1
Параметр signal выдаст команду на статистику ввода-вывода, поэтому вам не нужно ждать, пока она завершится (см. man dd
).
Кроме того, клиенты должны демонстрировать увеличение своего потребления полосы пропускания из-за энтропии, считываемой с сервера (например: nethogs
плюс netstat
).