Перефразирую. К примеру мой сервер:
CPU: Intel(R) Xeon(R) E-2124 CPU @ 3.30GHz (4 core)
MEM: MemTotal:       32658300 kB
LAN: 1Gbps
На нагрузочном тесте показал 3790 параллельных вызовов при 70% загрузки ЦПУ. У вас же один агент способен в один конкретный промежуток времени вести диалог с одним клиентом. Это 500 вызовов. Ну, допустим, еще по 1 клиенту у каждого агента в ожидании. Итого 1000. Один сервер легко потянет все ваши хотелки. Исключение, конечно, может быть  в том случае, если агенты до вашей АТС имеют завышенное время отклика. (Ну скажем Куба с их спутниковым инетом) Тогда, конечно, есть смысл ставить отдельную АТС на их территории для обслуживания местного населения.

И так. Полагаю, вам будет достаточно двух серверов в режиме мастер-слейв.

Если же хотите экзотики, то смотрите в сторону Kamailio, как балансировцик, маршрутизатор и сервер регистрации, с подлюченными к нему астерисками в требуемом количестве. Где-то видел на опеннет сию схему. Сейчас поищу.

Ох уж эти синтетические тесты)

Обычно такое тестирование не подразумевает сопутствующей нагрузки, записей в базу, записей (и конвертациии) разговоров., обработки диалплана и прочей сложной логики

Вопрос реально трудозатрат: на реализацию и на поддержку потом. Если делать на голом диалплане как умею это долго и потом поддерживать сложно.
Я бы хотел упор сделать все равно на разделении всего и взаимодействии по сети, что-то типа микросервисной модели. Типа есть какой-то дефолтный контейнер с астером, он запускается с примонтированными конфигами, в которых минимум настроек и коннектится по сети через FastAGI на адрес, на котором работает контейнер с тупым TCP-балансировщиком (например, HAproxy и тоже элементарный конфиг и дефолтный контейнер), этот балансировщик с помощью service-discovery находит работающий и "здоровый" контейнер(ы) с моим приложением и пересылает сетевые запросы в него. Если приложение перестаёт работать, то service-discovery или те же health-check в Haproxy моментально узнают об этом и HAproxy переключается на другой живой контейнер с моим приложением.
Соответственно сервисы с базой, хранилищем для файлов и т.п. тоже реплицированы.
Звонки тоже можно кстати балансировать через haproxy на несколько контейнеров с астером.

А вы, простите, перед сдачей сервера в коммерческую эксплуатацию его не тестируете и ждете, пока грабли по лбу ударят в продакшене?

Выглядит так, как будто FastAGI - это то что вам и нужно, ari и ami вам тут только усложнят жизнь

Вот в этом и был вопрос.

Да конечно! ))) И пишу в файлы и пишу в базу.
Вот выдержка из тогдашнего теста:
в общем, гиг интерфейс точно не отдает. и так. результаты:

Было совершено 6980 звонков. продолжительность каждого по 2 минуты. Генерил по 10 звоков в секунду. Таким образом пик должен был наступить где-то на 4000 акивных каналов

На софтфоне качество контролировал "на слух" по радио. (номер 60000)

Порог в 3257 активных вызовов считаю допустимым и работоспособным.
При превышении данного порога на +58 стали слышны артефакты (радио)
Транки, поднятые на сервере, не падали и работали на всем протяжении теста
Загрузка ЦПУ в пике не превышала 70% (есть запас в 20%)

Максимальное количество параллельных звонков - 3614 при этом обнаружено 11 случаев невозможности установить соединение. Причина - потери udp трафика на сетевом интерфейсе.

Узкое место - пропускная способность канала, к которому подключен данный сервер. Если этот недостаток устранить, то сервер без проблем выйдет на расчетные 4000+ параллельных вызовов

Ну возможно ещё AMI для задач типа сбора инфы о звонке (когда начался, когда закончился, почему). Ну или можно cdr для этих целей использовать, смотря какая детализация нужна

И все же это сферические тесты в вакууме. С реальными данными в рабочих системах может сильно разнится.

Вопрос в другом. Лично вы как сдаете сервер в коммерческую эксплуатацию? Без теста? Без промежуточной, технической эксплуатации в режиме дебага?

Пока у нас только тестовый стенд. Сейчас этим и занимаемся

для этого есть CDR & CEL и отдельностоящая реляционная база (если уже есть в том необходимость). Не изобретайте велосипед.