Вы когда-нибудь видели по-настоящему большой виртуализированный астериск?
24 ядра, но по 2.4GHz, 32ГБ памяти... что-нибудь в таких размерах да еще и с кучей скриптов и тяжеловесных модулей вроде CEL/CDR кучей ARI-стазисов и еще и внутренних AGI-подпрограмм.Может так случиться, что накладные расходы на переключение контекста приведут к полной деградации сервисов, при утилизации 20-40%. Скажем так. Если у вас 14000 переключений контекста на 1 ядро - конец близок. Добавьте накладные расходы на виртуализацию и каждый CS становится золотым!
Да-да. Переключение контекстов в системе может быть основной и центральной метрикой по загрузке (не CPU%) в особых случаях! Asterisk не единственный такой, есть еще Citrix Virtual Apps and Desktops (бывшие XenApp/XenDesktop). И если службы терминалов достаточно просто горизонтально смасштабировать по какому-то принципу, то с Asterisk ситуация может быть очень разная.
Просто приведу пример с *, вдруг кому-то пригодится:
1. Избавиться от лишних кодеков. У вас должен быть один кодек G711 a-law, тот который стандартизирован для РФ.
2. Если у вас есть требования на G711 μ-law или T.38 вам нужно от них избавиться по причине того, что сейчас уже 2020-й год, а факсы - остались в 20-ом. Для людей которые любят традиции и жизнь прошлым, можно поставить gateway T.38 -> e-mail а исходящие факсы запретить административно. Накрайняк, можно и наоборот замутить, но это решение крайне специфично для конкретной инфраструктуры... вообще если вы работаете в компании, которая хочет отправлять факсы в 2020-ом году, то это повод искать новую работу.
3. работа с ISDN E1 и SS7 должна производиться на отдельном железе, которое нужно притранковать. Оно же вам должно всё закодировать через g711a.
4. Избавьтесь от IAX. Мат-фильтр opennet не пропустит комментарий, если я буду объяснять, что я думаю об этом протоколе. Ограничимся тем, что оно не должно было существовать изначально. Оно порождает не только проблемы с производительностью, но и с качеством.
5. CHAN_SIP должен гореть в соседнем котле рядышком с IAX2, переход на PJSIP увеличивает реальную утилизацию на ~30-40% при том же количестве контекстов. Деградация снизится, будет расти эффективность в виду внетренней архитектуры * и как он работает с потоками.
5. Регистрация - это слабое место PJSIP. Увеличение утилизации в одном случае (звонок) даёт рост КПД, в другом случае (регистрация) выливается в рост потребления ресурсов при старте. Перезагрузка сервера с 4000 пользователей может и снова его уронить. Вынос регистрации на отдельное железо решает проблему. И совсем не обязательно, чтобы там был именно *. С этой задачей превосходнос правится kamailio.
6. AGI - это дорого и жирно. Нужно сеcть с разработчиками и пересмотреть архитектуру решения либо в сторону максимального перехода на ARI либо, если не получается, написать небольшой сервер приложений на любом языке программирования, выбросив поганые python-скрипты, заменяя их веб-сервисами (можно и на python :)
7. Когда монстр похудел, пора задуматься о виртуальном сетевом адаптере. E1000/E1000E - на помойку сразу. В идеале адаптер должен подаваться через SR-IOV. Эти виртуальные адаптеры также порождают огромные накладные расходы по контекстам. Если в арсенале нет ничего лучше vmxnet - поставьте нормальный гипервизор hyper-v или KVM.
8. Снизьте накладные расходы на виртуализацию. У вас должен быть 1 сокет с фиксированным количеством памяти без всяких поползновений. Приоритеты по частотам у каждого настраиваются по-своему. Strict NUMA вам в помощь вплоть до привязки конкретных ядер конкретных камней.
9. Дальше вы включаете мониторинг и меряете переключение контекстов сутки. Относительно ПИКОВОГО значения рассчитываете количество ядер на каждые 14000 переключений. Докидываете и продолжаете следить.
> насколько же велики эти накладные расходы по переключению контекста?
я видел и 470 000 CS через vmstat
