По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Проблемы с производительностью виртуальной машины на ESX/ESXi могут быть вызваны по различным причинам, например, ограничения в работе CPU, излишний объём памяти, задержкой в работе хранилищ или сети. Если одна или более из ваших виртуальных машин показывает высокое время ответа, то проверьте каждую из возможных причин, чтобы выявить слабое место системы. Неисправности Сервисы на гостевых виртуальных машинах работают медленно Приложения на гостевых виртуальных машинах отвечают с задержкой Гостевая виртуальная машина работает медленно или не отвечает Решение Каждый нижестоящий шаг содержит инструкции и ссылки на соответствующие документы. Шаги выстроены в наиболее удобном порядке для выявления и решения проблемы. Такая последовательность также обеспечивает наименьшую потерю данных. Замечание: после завершения каждого шага отмечайте сохраниться ли проблема с производительностью. Не пропускайте шаги и выполняйте их в указанном порядке. Статья включает в себя 4 основных части: Ограничения в работе CPU Излишний объём памяти Задержка в работе хранилища Сетевые задержки Ограничения в работе CPU Чтобы определить являются ли ограничения в работе CPU причиной низкой производительности: Введите команду esxtop, чтобы проверить перегружен ли ESXi/ESX server. Изучите load average в первой строке вывода команд. Средняя загрузка на уровне 1.00 означает, что физические процессоры (CPUs) машины с ESXi/ESX Server используются полностью, средняя загрузка 0.5 означает использование лишь половины ресурсов. Средняя загрузка на уровне 2.00 означает, что система перегружена. Изучите поле %READY, чтобы узнать долю времени, в течении которого виртуальная машина была готова, но не могла быть запланирована для запуска на физическом процессоре. При нормальных условиях эксплуатации это значение должно оставаться в пределах 5%. Если время готовности на виртуальных машинах с низкой производительностью слишком высокое, то необходимо проверить ограничения в работе процессора - убедитесь, что виртуальная машина не ограничена установленным лимитом процессора; Проверьте не ограничена ли виртуальная машина доступным объёмом ресурсов. Если средняя загрузка слишком высока и время, в течении которого машина готова к работе, не зависит от ограничений в работе процессора, то следует отрегулировать загрузку CPU хостa. Чтобы отрегулировать загрузку CPU хоста нужно: Увеличить количество физических CPU хоста Или уменьшить количество выделенных хосту виртуальных CPU. Чтобы уменьшить количество выделенных хосту виртуальных CPU нужно уменьшить общее количество CPU, выделенных всем запущенным виртуальным машинам на ESX хосте. Или уменьшить количество запущенных виртуальных машин Если Вы используете ESX 3.5, проверьте является ли проблемой совместное использование IRQ. Перегрузка памяти Чтобы определить является ли причиной низкой производительности перегрузка памяти необходимо: Ввести команду esxtop и установить перегружена ли память ESXi/ESX server. Изучите MEM overcommit avg в первой строке вывода команд. Это значение отражает соотношение требуемого объёма памяти к объёму доступной памяти, минус 1. Пример Если виртуальной машине требуется 4 ГБ ОЗУ и хост имеет 4 ГБ ОЗУ, то соотношение равно 1:1. После вычитания 1 (из 1:1) поле MEM overcommit avg выдаст значение 0. Память не перегружена и нет необходимости в дополнительном объёме. Если виртуальной машине требуется 6 ГБ ОЗУ и хост имеет 4 ГБ ОЗУ, то соотношение равно 1.5:1. После вычитания 1 (из 1:1) поле MEM overcommit avg выдаст значение 0. Память перегружена на 50% и необходимо на 50% больше ОЗУ, чем доступно. Если память перегружена, то следует отрегулировать количество памяти хоста. Для этого необходимо: Увеличить количество физической ОЗУ хоста Или уменьшить количество памяти, выделяемое виртуальным машинам. Для уменьшения объёма выделенной ОЗУ нужно уменьшить общее количество ОЗУ, выделенной всем виртуальным машинам хоста Или уменьшить общее количество виртуальных машин хоста. Определить состояние виртуальных машин: ballooning или swapping Для определения состояния: Запустите esxtop Введите m для памяти Введите f для полей Выберите букву J для Memory Ballooning Statistics (MCTL) Посмотрите на значение MCTLSZ. MCTLSZ (MB) отображает количество физической памяти гостя, переданной balloon driver. Введите f для поля Выберите букву для Memory Swap Statistics (SWAP STATS) Посмотрите на значение SWCUR. SWCUR (MB) отражает текущую загрузку свопа Для решения этой проблемы убедитесь, что ballooning или swapping не вызваны неправильно заданным объёмом памяти. Если объём памяти задан неверно, то его следует переназначить Задержки в работе хранилища Чтобы определить являются ли задержки в работе хранилища причиной низкой производительности: Проверьте связаны ли проблемы с локальным хранилищем. Перенесите виртуальные машины в другое хранилище. Уменьшите количество виртуальных машин на LUN. Поищите похожие записи на Windows гостей: The device, DeviceScsiPort0, did not respond within the timeout period Используя esxtop найдите высокое время задержки DAVG. Определите максимальную пропускную способность ввода/вывода с помощью команды iometer. Сравните результаты iometer, полученные на VM, с результатами физической машины с этим же хранилищем. Проверьте наличие конфликтов с резервированием SCSI. Если вы используете iSCSI хранилище и Jumbo фреймы, то следует проверить правильность конфигурации. При использовании iSCSI хранилища и многоканального iSCSI Software Initiator убедитесь, что всё правильно сконфигурировано. Если вы обнаружили проблемы, связанные с хранилищем: Убедитесь в том, что ваша аппаратура и HBA карты сертифицированы для работы с ESX/ESXi. Проверьте обновления вашего физического сервера. Проверьте обновления прошивки вашего HBA. ESX верно определяет режим и политику пути для вашего SATP Storage вашего типа и PSP Path Selection. Сетвые задержки Производительность сети тесно связана с производительностью CPU. Поэтому сначала необходимо проверить работу CPU и после этого переходить к поиску проблем в сети. Для определения проблем с производительностью сети: Проверьте максимальную пропускную способность от виртуальной машины с помощью Iperf. Замечание: VMware не поддерживает и не рекомендует какую-либо конкретную стороннюю программу. Во время использования 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 между двумя виртуальными машинами на общем сервере/portgroup/vswitch. Если результат положительный, то можно исключить проблемы с памятью, CPU и хранилищем. Если вы обнаружили «бутылочное горлышко» вашей сети, то: Если вы используете iSCSI хранилище и Jumbo фреймы, то следует проверить правильность конфигурации. Если вы используете Network I/O Control, то необходимо проверить правильность конфигурации общих ресурсов и ограничений для вашего траффика. Убедитесь в правильности работы трафик шейпинга.
img
В данной статье будет описан процесс настройки вашей АТС Asterisk с провайдером Zadarma. Настройка с помощью файлов конфигурации Asterisk Важный момент - у вас уже должны быть логин и пароль для данного провайдера, получить которые можно на сайте. Для примера будут указаны следующие данные: 1234567 - ваш SIP - номер, полученный при регистрации, ****** - ваш пароль и 321 - номер экстеншена. Рассмотрим самый стандартный вариант, при котором исходящие звонки с вышеуказанного внутреннего номера (экстеншена) маршрутизируются через SIP - транк zadarma-trunk. Для начала настройки необходимо отредактировать файл sip.conf следующим образом: [general] srvlookup=yes [zadarma-trunk] host=sip.zadarma.com insecure=invite,port type=friend fromdomain=sip.zadarma.com disallow=allallow=alaw&ulaw dtmfmode=autosecret=password defaultuser=1234567 trunkname=zadarma-trunk fromuser=1234567 callbackextension=zadarma-trunk context=zadarma-in qualify=400 directmedia=no [321] secret=password host=dynamic type=friend context=zadarma-out Настройки маршрутизации производятся в файле extensions.conf следующим образом: [zadarma-in] exten => 1234567,1, Dial(SIP/321) [zadarma-out] exten => _XXX,1,Dial(SIP/${EXTEN}) exten => _XXX.,1,Dial(SIP/${EXTEN}@zadarma-trunk) Для контекста [zadarma-in] все входящие вызовы направляются на экстеншен 321, и для [zadarma-out] возможны два варианта: если в набираемом номере 3 цифры, то вызов пойдет на один из экстеншенов, настроенных на вашей АТС, если же 4 и больше - вызов уйдет на транк zadarma-trunk. В случае, если ваша АТС находится не за маршрутизатором, а имеет публичный IP-адрес, то входящие вызовы можно принимать по следующей схеме, с использованием SIP URI. К примеру, 12039485767 - ваш DID номер подключенный к Zadarma, а 200.132.13.43 - адрес вашего Asterisk. Для этого нужно в личном кабинете в поле Настройки-Прямой телефонный номер нужно указать маршрутизацию с прямого DID номера на внешний сервер (SIP URI) в формате 12039485767@200.132.13.43 и отредактировать sip.conf следующим образом: [zadarma] host=sipde.zadarma.com type=friend insecure=port,invite context=zadarma-in disallow=all allow=alaw&ulaw dtmfmode = auto directmedia=no [zadarma2] host=siplv.zadarma.com type=friend insecure=port,invite context=zadarma-in disallow=all allow=alaw&ulaw dtmfmode = auto directmedia=no [zadarma3] host=sipfr.zadarma.com type=friend insecure=port,invite context=zadarma-in disallow=all allow=alaw&ulaw dtmfmode = auto directmedia=no Указываем исходящий маршрут в файле extensions.conf [zadarma-in] extended => 12039485767,1,Dial(SIP/321) Далее будет рассмотрена настройка транка для FreePBX 13 версии. Настройка с помощью FreePBX Важный момент, перед настройкой транка необходимо включить функцию SRV Lookup. Для этого необходимо пройти по пути Settings → Asterisk SIP Settings → Chan SIP Settings и для опции Enable SRV Lookup выбрать опцию Yes. Далее происходит уже знакомый процесс настройки транка – переходим во вкладку Connectivity → Trunks. Необходимо нажать на кнопку + Add Trunk и добавить chan_sip транк Присваиваем имя транку – в данном случае это «Zadarma_test» Далее необходимо перейти во вкладку sip Settings и указать настройки для входящей и исходящей связи (вкладки Outgoing и Incoming) Для удобства копирования, приведу настройки SIP - транка и строки регистрации в текстовом виде: host=sip.zadarma.com insecure=invite,port type=friend fromdomain=sip.zadarma.com disallow=all allow=alaw&ulaw dtmfmode=auto secret=****** defaultuser=1234567 fromuser=1234567 qualify=400 directmedia=no 1234567:******@sip.zadarma.com/1234567 Далее нужно нажать на Submit и Apply Config. Переходим к настройке входящего маршрута Маршрутизация Во вкладке Connectivity → Inbound Routes по уже знакомому способу создаём входящий маршрут (кнопка + Add Inbound Route), присваиваем описание и указываем номер. Далее нажимаем Submit и переходим к настройке исходящего маршрута: переходим по пути Connectivity → Outbound Route, создаём новый исходящий маршрут таким же образом как и входящий и указываем следующие параметры – имя маршрута, CID маршрута и используемый транк (тот, что был настроен в начале всего процесса.) Последним шагом является настройка Dial Patterns – переходим в одноименную вкладку и после поля префикс необходимо поставить одну единственную точку – иначе не будет возможности совершать исходящие вызовы. После этого необходимо нажать Submit и Apply Config. На этом настройка заканчивается.
img
В продолжение статьи про Docker, сегодня мы расскажем про Dockerfile — скрипт, который позволяет автоматизировать процесс построения контейнеров — шаг за шагом, используя при этом base образ. Докерфайлы и синтаксис для их создания Как уже было сказано выше, каждый Докерфайл — по сути скрипт, который автоматически выполняет определенные действия или команды в base образе, для формирования нового образа. Все подобные файлы начинаются с обозначения FROM — также как и процесс построения нового контейнера, далее следуют различные методы, команды, аргументы или условия, после применения которых получится Docker контейнер. Для начала, быстренько пройдемся по синтаксису — он, кстати говоря, крайне простой, с командами, говорящими самими за себя. В Докер файлах содержится два типа основных блоков — комментарии и команды с аргументами. Причем для всех команд подразумевается определенный порядок — подробнее об этом ниже. Ниже типичный пример синтаксиса, где первая строка является комментарием, а вторая — командой. # Print «Hello from Merionet!» RUN echo «Hello from Merionet!!» Перед тем, как переходить к собственно написанию собственно Докерфайла, сначала разберем все возможные команды. Все команды в Докерфайлах принято указывать заглавными буквами — к примеру RUN, CMD и т.д. Команда ADD — данная команда берет два аргумента, путь откуда скопировать файл и путь куда скопировать файлы в собственную файловую систему контейнера. Если же source путем является URL (т.е адрес веб-страницы) — то вся страница будет скачена и помещена в контейнер. # Синтаксис команды: ADD [исходный путь или URL] [путь назначения] ADD /my_merionet_app /my_merionet_app Команда CMD — довольно таки похожая на команду RUN, используется для выполнения определенных программ, но, в отличие от RUN данная команда обычно применяется для запуска/инициации приложений или команд уже после их установки с помощью RUN в момент построения контейнера. # Синтаксис команды: CMD %приложение% «аргумент», «аргумент», .. CMD «echo» «Hello from Merionet!». Команда ENTRYPOINT устанавливает конкретное приложение по умолчанию, которое используется каждый раз в момент построения контейнера с помощью образа. К примеру, если вы установили определенное приложение внутри образа и вы собираетесь использовать данный образ только для этого приложения, вы можете указать это с помощью ENTRYPOINT, и каждый раз, после создания контейнера из образа, ваше приложение будет воспринимать команду CMD, к примеру. То есть не будет нужды указывать конкретное приложение, необходимо будет только указать аргументы. #Синтаксис команды: ENTRYPOINT %приложение% «аргумент» # Учтите, что аргументы опциональны — они могут быть предоставлены командой CMD или #во время создания контейнера. ENTRYPOINT echo #Синтаксис команды совместно с CMD: CMD «Hello from Merionet!» ENTRYPOINT echo Команда ENV используется для установки переменных среды (одной или многих). Данные переменные выглядят следующим образом «ключ = значение» и они доступны внутри контейнера скриптам и различным приложениям. Данный функционал Докера, по сути, очень сильно увеличивает гибкость в плане различных сценариев запуска приложений. # Синтаксис команды: ENV %ключ% %значение% ENV BASH /bin/bash Команда EXPOSE используется для привязки определенного порта для реализации сетевой связности между процессом внутри контейнера и внешним миром — хостом. # Синтаксис команды: EXPOSE %номер_порта% EXPOSE 8080 Команда FROM — данную команду можно назвать одной из самых необходимых при создании Докерфайла. Она определяет базовый образ для начала процесса построения контейнера. Это может быть любой образ, в том числе и созданные вами до этого. Если указанный вами образ не найден на хосте, Докер попытается найти и скачать его. Данная команда в Докерфайле всегда должна быть указана первой. # Синтаксис команды: FROM %название_образа% FROM centos Команда MAINTAINER — данная команда не является исполняемой, и просто определяет значение поля автора образа. Лучше всего ее указывать сразу после команды FROM. # Синтаксис команды: MAINTAINER %ваше_имя% MAINTAINER MerionetNetworks Команда RUN - является основной командой для исполнения команд при написании Докерфайла. Она берет команду как аргумент и запускает ее из образа. В отличие от CMD данная команда используется для построения образа (можно запустить несколько RUN подряд, в отличие от CMD). # Синтаксис команды: RUN %имя_команды% RUN yum install -y wget Команда USER — используется для установки UID или имени пользователя, которое будет использоваться в контейнере. # Синтаксис команды: USER %ID_пользователя% USER 751 Команда VOLUME — данная команда используется для организации доступа вашего контейнера к директории на хосте (тоже самое, что и монтирование директории) # Синтаксис команды: VOLUME [«/dir_1», «/dir2» ...] VOLUME [«/home»] Команда WORKDIR указывает директорию, из которой будет выполняться команда CMD. # Синтаксис команды: WORKDIR /путь WORKDIR ~/ Создание своего собственного образа для установки MongoDB Для начала создадим пустой файл и откроем его с помощью vim: vim Dockerfile Затем мы можем указать комментариями для чего данный Докерфайл будет использоваться и все такое — это не обязательно, но может быть полезно в дальнейшем. На всякий случай напомню — все комментарии начинаются с символа #. ######## # Dockerfile to build MongoDB container images # Based on Ubuntu ######## Далее, укажем базовый образ: FROM ubuntu Затем, укажем автора: MAINTAINER Merionet_Translation После чего обновим репозитории(данный шаг совершенно необязателен, учитывая, что мы не будем их использовать ) : RUN apt-get update После укажем команды и аргументы для скачивания MongoDB (установку проводим в соответствии с гайдом на официальном сайте): RUN apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 7F0CEB10 RUN echo 'deb http://downloads-distro.mongodb.org/repo/ubuntu-upstart dist 10gen' | tee /etc/apt/sources.list.d/mongodb.list RUN apt-get update RUN apt-get install -y mongodb-10gen RUN mkdir -p /data/db После чего укажем дефолтный порт для MongoDB: EXPOSE 27017 CMD [«--port 27017»] ENTRYPOINT usr/bin/mongod Вот как должен выглядеть у вас финальный файл — проверьте и, затем, можно сохранить изменения и закрыть файл: ######### # Dockerfile to build MongoDB container images # Based on Ubuntu ######### FROM ubuntu MAINTAINER Merionet_Translation RUN apt-get update RUN apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 7F0CEB10 RUN echo 'deb http://downloads-distro.mongodb.org/repo/ubuntu-upstart dist 10gen' | tee /etc/apt/sources.list.d/mongodb.list RUN apt-get update RUN apt-get install -y mongodb-10gen RUN mkdir -p /data/db EXPOSE 27017 CMD ["--port 27017"] ENTRYPOINT usr/bin/mongod Запуск контейнера Docker Итак, мы готовы создать наш первый MongoDB образ с помощью Docker! sudo docker build -t merionet_mongodb . -t и имя здесь используется для присваивания тэга образу. Для вывода всех возможных ключей введите sudo docker build —help, а точка в конце означает что Докерфайл находится в той же категории, из которой выполняется команда. Далее запускаем наш новый MongoDB в контейнере! sudo docker run -name MerionetMongoDB -t -i merionet_mongodb Ключ -name используется для присвоения простого имени контейнеру, в противном случае это будет довольно длинная цифро-буквенная комбинация. После запуска контейнера для того, чтобы вернуться в систему хоста нажмите CTRL+P, а затем CTRL+Q. Заключение Всем спасибо за внимание, теперь вы можете очень много экспериментировать с созданием Докерфайлов и ваших собственных образов, не бойтесь пробовать упростить привычные вам процессы установки приложений с помощью контейнеров — возможности крайне велики, и мы постараемся охватить их в следующих статьях.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59