У меня есть несколько ключей энтропии с egd перед ними, а затем вся нагрузка уравновешивается haproxy. Затем у меня есть много клиентских машин, использующих IP-адрес службы haproxy в качестве сетевого источника энтропии. Я понятия не имею, сколько энтропии они запрашивают.
Ключи энтропии могут производить ограниченное количество полезной энтропии. В характеристиках указано минимум 30 килобит / сек. Насколько я понимаю, у ключа энтропии нет способа узнать, сколько он запрашивается. Протокол EGD кажется довольно трудным для поиска этой информации. Клиенты могут запрашивать переменное количество энтропии, и они могут не получить обратно то же количество.
Кто-нибудь нашел простой способ измерить, сколько запрашивается с ключа энтропии?
Было бы неплохо знать, чтобы иметь возможность спланировать, когда потребуются дополнительные ключи, и выявлять нестабильных клиентов.
Единственные две вещи, которые приходят на ум, - это попытка измерить время отклика вашего энтропийного сервера (должно быть значительное увеличение задержки, если он не успевает за ним) или объединение /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).