По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В этой статье поговорим о локализации проблем функционирования ESXi/ESX.
Неисправности. Что может быть не так?
ПО, работающее в гостевой виртуальной машине - медленно реагирует на команды управления;
ПО, работающее в гостевой виртуальной машине, периодически прерывают работу;
Гостевая виртуальная машина работает медленно или не отвечает на запросы.
Проблемы с производительностью могут случаться из-за ограничений центрального процессора (CPU), переполнения памяти или, например, задержкой сети. Если виртуалки работают плохо, скорее всего имеют место траблы с памятью. Устраним?
Решение (воркэраунд)
Ограничения центрального процессора (проблемы CPU)
Чтобы определить, связана ли низкая производительность виртуалки с ограничением центрального процессора, надо:
Используйте команду esxtop для того, чтобы определить основные параметры производительности аппаратного сервера виртуалки
Проверьте командой load average загрузку. Если среднее значение нагрузки равно 1.00 , то физические ЦП (центральные процессоры) гипервизора ESXi/ESX полностью используются, а среднее значение нагрузки, равное 0.5, значит, что используются наполовину. Логика, думаю, вам понятна. Значение нагрузки, равное 2.00, означает, что система в целом переполнена (бегите в серверную с огнетушителем 👀)
Проверьте поле %READY на процент времени на момент, когда виртуальная машина была готова, но не смогла запуститься на физическом ЦП. При нормальных условиях эксплуатации это значение должно находиться в пределах 5%. Если это значение высокое, и виртуальная машина имеет плохую производительность, тогда проверьте ограничение центрального процессора:
Убедитесь, что на виртуальной машине не установлен предел ЦП.
Убедитесь, что на виртуальной машине не установлен пул ресурсов (Resource Pool).
Если среднее значение нагрузки слишком высокое и время ожидания не вызвано ограничением центрального процессора, тогда отрегулируйте нагрузку ЦП на хост. Чтобы настроить нагрузку на хост, выполните следующие шаги:
Увеличьте значение физического ограничения ЦП на хост
Или уменьшите виртуальное ограничение ЦП, выделенное хосту. Чтобы уменьшить это ограничение, сделайте:
Уменьшите общее количество ЦП, выделенных всем виртуальным машинам, работающих на узле ESX
Или уменьшите количество виртуальных машин, работающих на хосте (но это весьма грубый способ, как мы считаем)
Если Вы используете ESX 3.5, проверьте доступ к IRQ.
Переполнение памяти
Чтобы определить, связана ли низкая производительность с избыточностью памяти:
Используйте команду esxtop для того, чтобы определить основные параметры производительности аппаратного сервера виртуалки.
Проверьте параметр MEM в первой строке вывода. Это значение отражает отношение запрошенной памяти к доступной, минус 1. Например:
Если виртуальным машинам требуется 4 ГБ ОЗУ, а хост имеет 4 ГБ ОЗУ, то справедливо соотношение 1:1. После вычитания 1 (из 1/1) поле MEM overcommit avg считывает 0. Вывод - избытка нет и не требуется дополнительной оперативной памяти.
Если виртуальным машинам требуется 6 ГБ ОЗУ, а хост имеет 4 ГБ ОЗУ, то есть соотношение 1,5:1. После вычитания 1 (из 1,5/1), поле overcommit avg МЭМ считывает 0,5. Объем оперативной памяти превышен на 50%, что означает, что требуется на 50% больше доступной оперативной памяти.
Если память перегружается, отрегулируйте нагрузку на хост. Чтобы настроить нагрузку на память, выполните следующие действия:
Увеличьте количество физической оперативной памяти на хосте
Или уменьшите объем оперативной памяти, выделенной виртуальным машинам. Для уменьшения объема выделенной оперативной памяти:
Уменьшите общий объем оперативной памяти, выделяемой всем виртуальным машинам на узле
Или уменьшите общее число виртуальных машин на узле.
Определите, являются ли виртуальные машины "раздувающимися" или/и заменяемыми. Для обнаружения раздувания или замены:
Запустите esxtop
Введите m для просмотра памяти
Введите f для управления колонками вывода (полями)
Выберите букву J в поле Memory Swap Statistics "Статистика раздувания памяти" (MCTL)
Посмотрите на значение MCTLSZ. MCTLSZ (MB)отображает объем физической памяти гостя, возвращаемой драйвером баллона (Memory Ballooning).
Введите f для управления колонками вывода (полями)
Выберите букву для статистики свопов памяти (SWAP STATS)
Посмотрите на значение SWCUR. SWCUR (MB) отображает текущее использование обмена.
Чтобы устранить эту проблему, убедитесь, что раздувание и/или замена не вызваны неправильно установленным пределом памяти
Период ожидания запоминающего устройства
Чтобы определить, связана ли низкая производительность с задержкой хранения данных:
Определите, связана ли проблема с локальным хранилищем. Если связана, то перенесите виртуальные машины в другое место хранения.
Уменьшите количество виртуальных машин на одно логическое устройство.
Найдите записи журнала в Windows guests, которые выглядят следующим образом: The device, DeviceScsiPort0, did not respond within the timeout period.
Используя esxtop, найдите высокое время задержки DAVG.
Определите максимальную пропускную способность ввода-вывода, которую можно получить с помощью команды iometer.
Сравните результаты iometer для виртуальной машины с результатами для физической машины, подключенной к тому же хранилищу.
Проверьте наличие конфликтного обращения к ресурсу SCSI.
Если вы используете ресурсы хранения iSCSI и группу данных jumbo, убедитесь, что все настроено правильно.
Если вы используете ресурсы хранения iSCSI и передачу по нескольким трактам с использованием программного инициатора iSCSI, убедитесь, что все настроено правильно.
При выявлении проблемы, связанной с хранением:
Убедитесь, что аппаратный массив устройства и платы HBA сертифицированы для ESX/ESXi.
Убедитесь, что BIOS физического сервера обновлена.
Убедитесь, что встроенное ПО вашего HBA-адаптера обновлено.
Убедитесь, что ESX может распознать правильный режим и политику пути для типа массива хранения SATP и выбора пути PSP.
Задержка сети
На производительность сети может сильно влиять производительность ЦП. Исключите проблему производительности ЦП перед исследованием сетевой задержки.
Чтобы определить, вызвана ли низкая производительность задержкой сети, выполните следующие действия:
Проверьте максимальную пропускную способность виртуальной машины с помощью инструмента Iperf.
При использовании Iperf измените размер окон TCP на 64 K. Производительность также зависит от этого значения. Чтобы изменить размер окон TCP:
На стороне сервера введите следующую команду: iperf –s
На стороне клиента введите следующую команду: iperf.exe -c sqlsed -P 1 -i 1 -p 5001 -w 64K -f m -t 10 900M
Запустите Iperf с компьютера вне хоста ESXi/ESX. Сравните результаты с ожидаемыми, в зависимости от физической среды.
Выполните команду Iperf с другого компьютера вне хоста ESXi/ESX в той же VLAN на том же физическом коммутаторе. Если производительность хорошая, и проблему можно воспроизвести только на машине в другом географическом месте, то проблема связана с вашей сетевой средой.
Выполните команду Iperf между двумя виртуальными машинами на одном сервере ESX/portgroup/vswitch. Если результат хороший, можно исключить проблему с ЦП, памятью или хранилищем.
Если вы определяете параметры, которые ограничивают производительность системы в сети:
Если вы используете ресурсы хранения iSCSI и кадры jumbo, убедитесь, что все настроено правильно.
Если вы используете Network I/O Control,то убедитесь, что общие ресурсы и ограничения правильно настроены для вашего трафика.
Проверьте правильность настройки формирования траффика.
Для осуществления перенаправления вызовов по необходимым правилам прибегают к настройке входящих и исходящих маршрутов. Из названия ясно, что входящие маршруты отвечают за обработку входящих вызовов, а исходящие за обработку звонков в город. В статье расскажем о настройке обоих маршрутов в IP – АТС Elastix.
Настройка входящих маршрутов
Начнем с настройки маршрутизации для приходящих на нашу АТС звонков. Для этого, перейдем в раздел PBX → PBX Configuration → Inbound Routes. Перед нами откроется интерфейс настройки входящего маршрута:
В рядовом случае, маршрутизация осуществляется по параметру DID Number - это номер, который набрал звонящий. Например, у вас есть 2 номера: 74951234567 и 74957654321. Чтобы при звонке на первый номер вызовы уходили на оператора, а при звонке на второй номер на менеджера, нужно создать два отдельных маршрута. Чтобы Elastix смог отличить звонок на первый номер от звонка на второй, необходимо создать маршрут с DID Number 74951234567 с перенаправлением на оператора, и второй маршрут с DID Number 74957654321 с направлением на менеджера. Для того, чтобы входящие заработали, достаточно следующей настройки:
Рассмотрим прочие пункты настройки:
Add Incoming Route
Description - описание для создаваемого маршрута
DID Number - номер DID, который мы обсуждали ранее. Это номер, который набирает звонящий.
CallerID Number - в данном поле можно указать номер звонящего (CallerID). В данном случае маршрут будет проверять два условия: совпадения номера звонящего и набранного номера.
CID Priority Route - если вы хотите исключительно маршрутизировать звонок по номеру звонящего, то поставьте галочку в данном чекбоксе.
Options
Alert Info - если данный маршрут является обязательным (аварийным, например, для службы безопасности), мы можете оснащать заголовки SIP сообщений текстом в поле ALERT_INFO. Большинство устройств, получая текст в данном поле могут изменить сигнал звонка или автоматически ответить на звонок
CID name prefix - в данном поле разрешается подставить префикс для имени в составе Caller ID. Например, префикс Partner: на маршруте преобразует звонок с номера 74951234567 в Partner:74951234567
Music On Hold - музыка на удержании, для вызовов, которые отрабатываются по этому маршруту
Signal RINGING - посылать ли сигнал КПВ (Контроль посылки вызова) до ответа на звонок
Pause Before Answer - временная задержка перед обработкой вызова по правилам этого маршрута
Privacy
Privacy Manager - если вызов пришел без CallerID, то звонящему будет предложено ввести свой номера телефона в течение 3 попыток
Call Recording
Call Recording - записывать ли вызовы на данном маршруте
CID Lookup Source
Source - источник для преобразования номеров в имена. Осуществляется с помощью модуля CallerID Lookup Sources
Fax Detect
Detect Faxes - определять ли факсимильные сигналы на данном маршруте
Language
Language - настройка языка, который функционирует на данном маршруте. Например, маршрут может быть предназначен для звонящих из Германии, Франции или России. Настройка так же влияет на параметр Privacy Manager
Set Destination
Выбрать назначение для звонка из представленных
Настройка исходящих маршрутов
Теперь сделаем настройку маршрутов для исходящих вызовов. Переходим в раздел PBX → PBX Configuration → Outbound Routes:
В разделе рассмотрим краткую настройку модуля. Если вы хотите подробно ознакомиться о всеми опциями настройки, то перейдите по этой ссылке.
Итак, чтобы ваши телефоны смогли звонить в город, необходимо настроить следующие позиции:
Route Name - имя для маршрута
Dial Patterns that will use this Route - шаблон для отправки вызовов по этому маршруту. Если вы хотите отправлять все без разбора вызовы и без преобразования в транк, то в поле match pattern укажите . (точку)
Trunk Sequence for Matched Routes - транк, в который вызов будет отправляться по этому маршруту. Можно указать несколько, и, в случае, если первый транк будет не доступен, то будет использоваться следующий.
Прямо сейчас, пока ты читаешь эту статью, в серверной комнате организации А под толстым слоем пыли, окруженная множеством переплетенных проводов мигает разноцветными лампочками офисная АТС. Но давайте будем тише - дежурный IT - специалист, скорее всего спит, поставив переадресацию на мобильный телефон - а вдруг что - то сломается?
Вообще, облака, на своем старте - наделали шума. Все начали задаваться вопросом - а зачем нам сервер в офисе, когда можно арендовать VPS/VDS/SaaS в облаке и “не париться”?
В статье мы ответим на вопрос - почему одни компании выносят свою телефонию в облако или покупают услугу виртуальной АТС, тем самым создавая возможность поставить вендинговую машину или настольный теннис в серверной комнате, а другие, продолжают перебирать провода, протирать пыль с серверов и наслаждаться мерцанием цветовых серверных индикаторов от офисной АТС.
Бюджет: сравниваем облако и размещение в офисе
Первое, что стоит спросить себя - а как мы будем платить за АТС? Что для нас важно, а что нет? Мы, как интегратор, все чаще сталкиваемся с тем, что в компаниях (SMB) идет сокращение бюджета на IT и соответствующие отделы находят выходы из этой ситуации.
С точки зрения локальной (офисной) АТС - далее мы будем называть ее порой “on-premise” решение (говоря так, мы чувствуем себя немного круче), IT - отдел экономит деньги ежемесячной оплате хосту (SaaS платформе, которая дает вам услугу виртуальной АТС). Но эта экономия реальна только в том случае, если вы не меняете аппаратные компоненты сервера с АТС. В таком случае модель вы платите только за услуги провайдера, электричество и заработную плату IT’шнику. Модель “купил - запитал - работает, не трожь” работает, более чем.
Однако, в случае выхода из строя того или иного компонента, компания несет определенного рода дополнительные расходы. Отметим, опять же, на нашем опыте - случается это редко. Современные сервера имеют высокое качество комплектующих, и если вы не планируете поливать сервера водой, обдавать из огнемета или выставлять на улице - скорее всего, данная неприятность вам не грозит.
Не менее важный фактор - обновление ПО. Проблема в том, что если вы обновляете программное обеспечение офисной “on-premise” (да - да, мы же предупреждали) АТС, есть риск выхода из строя. Опять же, данная проблема решается простым резервированием, так называемой отказоустойчивостью, по принципу Active - Standby (один сервер активен, а второй в резерве и всегда готов выйти в активную роль). Этот нюанс требует дополнительной проработки, а следовательно, дополнительных денежных затрат.
Теперь про масштабируемость. В случае, если проснувшись в один прекрасный день вы осознаете, что ваш бизнес вырос в разы (вы сходили на бизнес - тренинг, к шаману или проделали магический обряд), то офисные локально размещенные станции масштабируются несколько сложнее и затратнее, чем виртуальные. Это отражается на деньгах и стоимости масштабирования.
Тут есть важный пункт - офисная АТС гораздо более гибка, чем виртуальная. Дело в том, что виртуальная АТС дается вам в неком готовом контейнере предустановок, где SaaS платформа редко дает возможность доработки станции. Да, признаем, некоторые облачные АТС имеют API, но когда вопрос заходит о масштабном изменении логики работы АТС (кастомизация скриптами, например) - тут происходит коллапс. В этом плане офисные АТС явно выигрывают перед облачными, несмотря на стоимость затрат на эту самую кастомизацию. Просто сам факт ее возможность при быстром росте бизнеса - это преимущество (поверьте, знаем о чем говорим на опыте разных проектов).
Редкие, но некоторые IT - отделы предпочитают облачную телефонию. Это более предсказуемо и снимает с них часть ответственности. Например, когда директор компании задает вопрос ITшнику почему не работает телефония, тот может смело спихнуть ответственность на виртуального хостера.
Модернизация и апгрейд: витаем в облаках или в офисе?
Тут пальму первенства заслуженно забирают облака. Дело в том, что если у вас в офисе живет on-premise АТС, так или иначе, рано или поздно вам придётся обновлять аппаратные компоненты сервера (процессор, оперативная память, наращивать мощность RAID массивов, тем самым увеличивая пространство для хранения данных). Это происходит по двум причинам: растёт нагрузка на сервер и текущие мощности уже не справляются, или обновление программного обеспечения требует более производительных комплектующих. При облачном размещении таких проблем нет - ваш хост автоматически наращивает мощности виртуальной машины, внутри которой живет ваша АТС. Это, безусловно, сказывается на мощности, но выходит дешевле покупки комплектующих под локальных сервак.
Кстати про обновление - в случае решения, размещённого в вашем офисе, обновление ПО производят ваши ITшники, тогда как при размещении в облаке, хост сам обновляет ПО и раскатывает их на боевую среду.
Интеграция телефонии с внешними системами
Любителям on-premise решений посвящается. Откиньтесь на диване поудобнее - в этой главе уже есть победитель. И это не облако.
Дело в том, что с ростом компании, уровень технологичности неизбежно повышается. Новые направления деятельности и увеличение потока клиентов обязывают связать ИТ - узлы в единую экосистему: интеграция телефонии и CRM, справочниками, базами данных, звонки по нажатию, триггерный автоматический обзвон, предиктивный дайлер и прочие. Все эти “хотелки” так или иначе требуют доработки вашей станции, так как интеграцию со всем на свете разработчики облачный виртуальных АТС предусмотреть не могут, а открыть исходный код и раздвинув горизонт кастомизации до бесконечности, рискуют получить уязвимости в безопасности.
Именно по этой причине, офисная коробка дает больше. Например: вы хотите сделать маршрутизацию на базе гороскопа клиента. В вашей CRM есть номер телефона клиента, имя и его дата рождения. При входящем звонке, телефония “смотрит” в вашу CRM и видит месяц рождения клиента (по номеру, с которого он звонит). Кастомная прослойка понимает - он рыба, а рыбам, сегодня не рекомендуется иметь деловых отношений. И на базе этого решения офисная телефонная станция терминирует вызов. Как вам?
Пожалуй, надо признать, пример весьма спорный. Но посыл понятен - коробка в офисе даст больший пул возможностей, а облако, максимум, обрезанный API.
Катастрофы: коробки или облако?
В офисе над вами прорвало трубу и залило серверную (мы реально встречали такие кейсы). Сервера вышли из строя, не работает ничего. Есть две новости, начнем с хорошей:
Сервер был на гарантии и имеется контракт на горячую замену от интегратора;
Сервера больше нет.
Несмотря на контракт горячей замены, просто в минимум 24 часа вам гарантирован (если не реализована схема отказоустойчивости с географически распределенными серверами по ЦОДам).
В облаке, как правило, SaaS дает вам гарантию работоспособности от 90%. Облачная вычислительная мощность живет в разных ЦОДах, при отказе аппаратного сервера, виртуальная машина с вашей ВАТС переедет на другой аппаратный сервер за сотые доли секунды. Что неплохо.
Тут, пожалуй, для SMB компании первенство мы отдадим облаку.
Итоги
Как облака, так и размещенные в офисе решения имеют свои преимущества. Если курс вашей компании на безграничную кастомизацию, интеграцию всех ИТ - систем между собой для создания экосистемы и амбициозные бизнес - процессы, у вас есть грамотный IT - специалист, то выбирайте коробку, которую вы разместите в офисе.
Если вы не хотите проблем с сервером, обслуживанием, вы малый бизнес, у вас нет своего IT’шника в штате и хотите рабочую телефонию с минимумом головной боли - облако подойдет под ваши требования.