По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
В этой статье поговорим о локализации проблем функционирования 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,то убедитесь, что общие ресурсы и ограничения правильно настроены для вашего трафика. Проверьте правильность настройки формирования траффика.
img
В обычной корпоративной сети доступ к серверам из филиалов организации может осуществляться, чаще всего, подключением к серверам, расположенным в центральном офисе. Но при расположении серверной инфраструктуры в облаке параметры связи рабочих станций с серверами будут зависеть уже не от канала связи от каждого конкретного филиала до центрального офиса, а от канала связи всех отделений организации с ЦОД облачного провайдера, чьими услугами пользуется организация для формирования облачной инфраструктуры. Переход в облака поставил перед разработчиками ПО и сетевыми инженерами ряд новых условий, вызывающих задержку сигнала, которые им приходится учитывать для формирования качественного доступа к данным в облаке. Например, задержка длительностью 500мс приводит к снижению трафика Google на 20%, а задержка в 100мс сокращает продажи Amazon на 1%. Время задержки может быть очень важным аспектом во время работы с виртуальными рабочими столами (VDI), потоковым вещанием, трейдингом, передовыми web-сервисами, базами данных, терминальными приложениями. Но задержка не столь критична для таких сервисов как электронная почта или работа с документами. QoS и SLA Существует проблема обеспечения необходимого качества обслуживания (QoS). Разные виды трафика имеют различные требования к рабочим характеристикам сети. Чувствительность видов трафика была взята из и показана в таблице 1 Таблица 1. Чувствительность различных приложений сетевым характеристикам Тип трафика Уровень чувствительности к сетевым характеристикам Полоса пропускания Потери Задержка Джиттер Голос Очень низкий Средний Высокий Высокий Электронная коммерция Низкий Высокий Высокий Низкий Транзакции Низкий Высокий Высокий Низкий Электронная почта Низкий Высокий Низкий Низкий Telnet Низкий Высокий Средний Низкий Поиск в сети "от случая к случаю" Низкий Средний Средний Низкий Постоянный поиск в сети Средний Высокий Высокий Низкий Пересылка файлов Высокий Средний Низкий Низкий Видеоконференция Высокий Средний Высокий Высокий Мультикастинг Высокий Высокий Высокий Высокий Рекомендации МСЭ-Т по обеспечению QoS для сетей описываются в рекомендациях Y.1540 - стандартные сетевые характеристики для передачи пакетов в сетях IP, и Y.1541 нормы для параметров, определенных в Y.1540. Данные рекомендации важны для всех участников сети: провайдеров и операторов, пользователей и производителей оборудования. При создании оборудования, планировании развертывания и оценке сетей IP, оценка качества функционирования сети все будут опираться на соответствие характеристик требованиям потребителей. Основные характеристики, рассматриваемые в рекомендации Y.1540: производительность сети; надежность сети/сетевых элементов; задержка; вариация задержки (jitter); потери пакетов. Подробнее о данных характеристиках следует прочитать в вышеназванных рекомендациях. В таблице 2 указаны нормы на определенными в Y.1540 характеристики и распределены по классам качества обслуживания (QoS). Таблица 2 - Нормы для характеристик сетей IP с распределением по классам QoS Сетевые характеристики Классы QoS 0 1 2 3 4 5 Задержка доставки пакета IP, IPTD 100 мс 400 мс 100 мс 400 мс 1 с Н Вариация задержки пакета IP, IPDV 50 мс 50 мс Н Н Н Н Коэффициент потери пакетов IP, IPLR 1х10 3 1х10 3 1х10 3 1х10 3 1х10 3 Н Коэффициент ошибок пакетов IP, IPER 1х10 4 1х10 4 1х10 4 1х10 4 1х10 4 Н Примечание: Н не нормировано. Рекомендация Y.1541 устанавливает соответствие между классами QoS и приложениями: Класс 0 приложения реального времени, чувствительные к джиттеру, характеризуемые высоким уровнем интерактивности (VoIP, видеоконференции); Класс 1 приложения реального времени, чувствительные к джиттеру, интерактивные (VoIP, видеоконференции); Класс 2 транзакции данных, характеризуемые высоким уровнем интерактивности (например, сигнализация); Класс 3 транзакции данных, интерактивные; Класс 4 приложения, допускающие низкий уровень потерь (короткие транзакции, массивы данных, потоковое видео) Класс 5 традиционные применения сетей IP. Таким образом некоторые из облачных сервисов вполне могут попадать в классы 0 и 1, а значит следует учитывать время задержки и стараться сделать так, чтобы она не превышала 100 мс. Задержки в сетях Подключение к облаку через VPN аналогично подключению к центральному офису организации по VPN, за исключением лишь того, что если в обычной корпоративной сети все филиалы организации подключались к центральному офису, то теперь подключение филиалов и центрального офиса в том числе будет осуществляться к ЦОД облачного провайдера. Для проверки задержки в большинстве ОС используется команда ping, а для проверки пути прохождения пакета команда tracert, которые подробнее рассмотрим ниже. Предположим, что домашняя сеть является подобием корпоративной сети малого предприятия. В таблице в приложении А собраны данные из статьи с указанием расположения ЦОД. Воспользуемся этими данными чтобы проверить задержку сигнала от текущей домашней сети, расположенной в городе Москва, без учета VPN, до web-сервера некоторых компаний, владеющих, ЦОД, расположенных в разных городах, тем самым проверяя разницу в задержке в зависимости от расположения ЦОД облачного провайдера. Для проверки задержки воспользуемся "Командной строкой" Windows и командами ping и tracert. Команда ping используется для проверки целостности и качества соединения в сети на основе протоколов TCP/IP. Команда tracert строит маршрут через коммутационные узлы между компьютером и конечным сервером и выводит их IP-адреса и время задержки. На рисунках 1 и 2 представлена системная справка по командам, соответственно, tracert и ping. Проведем тест проверки задержки до домена DataLine dtln.ru, расположенного ближе всего к домашней сети (рисунки 3 и 4). Как видно из результатов на рисунке 5.3, было передано и получено 4 пакета объемом 32 байта. Время обмена одним пакетом составило 1 миллисекунду. Команда tracert вывела следующие данные: 1, 2, 3 - номер перехода; <1 мс <1 мс <1 мс время ответа для 3-х попыток (в данном случае все попытки менее 1 мс); 185.3.141.232 IP-адреса (в данном случае IP-адрес домена dtln.ru) Согласно проверке данного IP на сайте 2ip.ru, данный домен базируется по тому же адресу на карте, что и указано в таблице в приложении Б. Таким образом можно сделать вывод, что web-сервер большинства компаний из списка вероятнее всего находится на территории одного из их ЦОД, но даже если и нет, то позволяет сделать выводы о доступности ресурса. Аналогично проверим ping для остальных компаний, результаты представим на рисунке 5.5. В качестве опорного времени задержки будет использовано среднее и максимальное время приема-передачи. Из данных рисунка 5 можно сделать вывод, что среднее значение времени задержки в пределах Москвы из сети, также находящейся в пределах Москвы, чаще всего не превышает 10мс. Можно сравнить данные значения с ping до серверов Amazon Web Services в разных регионах с сайта cloudping.info (рисунок 6). VPN без шифрования теоретически позволил бы сократить эту задержку в связи с использованием "прямого туннеля" между "офисом" и ЦОД. Шифрование будет вносить уже свою задержку, проверить которую в данных условиях нет возможности. В локальных сетях корпоративной сети и сети ЦОД задержка исчисляется в микросекундах. В сети ЦОД предъявляются высокие требования к быстродействию сети, современные решения Ethernet для ЦОД должны быть широкополосными и поддерживать скорости 10, 25, 40, 50, 100 Гбит/с, обеспечивать низкие задержки до 1-2 мкс для связи серверов (через три коммутатора), и многие другие. Скорость интернет-канала Передача видео через сети связи, будь то видео с камер наблюдения или же видеоконференции, являются одними из самых требовательных с скорости передачи данных. Если для работы с документами может быт достаточно скорости в 100 Кбит/с, то для передачи видео понадобится уже примерно 2 Мбит/с. Для некоторых приложений, таких как IP-телефония, желательно, чтобы уровень задержек был низким, а мгновенная пропускная способность канала была больше определенного порогового значения: не ниже 24 Кбит/с для ряда приложений IP-телефонии, не ниже 256 Кбит/с для приложений, обрабатывающих видеопоток в реальном времени. Для некоторых приложений задержки не так критичны, но, с другой стороны, желательна высокая пропускная способность, например, для передачи файлов. Например, компания Ivideon предлагает услуги облачного видеонаблюдения, и у них на сайте даются следующие требования к интернет-каналу для разного качества видеопотока. Данные представлены в таблице 3. Таблица 3 Требования к интернет-каналу для одной камеры видеонаблюдения при разных разрешения при частоте 25 кадров/сек Разрешение Качество изображения Рекомендуемая скорость 1280х720 (1Mpx) /25к/с 1 Мбит/с 1920x1080 (2Mpx) /25к/с 2 Мбит/с 2048x1536 (3Mpx) /25к/с 2 Мбит/с 2592x1728 (4Mpx) /25к/с 2 Мбит/с Но для работы с терминальными сессиями достаточно канала в 128-256 Кбит/с на пользователя. Для 50 пользователей понадобится 6.25 Мбит/с. Компания 1cloud.ru при выборе ширины канала связи предлагает скорость соединения в диапазоне от 10 до 100 Мбит/с для доступа к виртуальному серверу. Внутри облака сетевые соединения между виртуальными машинами имеют пропускную способность в 1 Гбит/с. RDP-сессия Для теста потребления трафика при использовании удаленного подключения RDP был проведен эксперимент. Два персональных компьютера находятся в одной локальной сети и подключены к интернету. Один выступает сервером удаленного доступа, второй подключается к нему посредством встроенной в Windows программы "Подключение к удаленному рабочему столу" по протоколу RDP. На сервере запускается видео в интернете. Для захвата трафика и анализа используется ПО Wireshark Параметры подключения: размер удаленного рабочего стола 1920х1080 глубина цвета 15 бит выбранная скорость соединения 56 Кбит/с дополнительные возможности отключены (рисунок 7) Wireshark программа для захвата и анализа сетевого трафика. Данная программа работает с подавляющим большинством известных протоколов, имеет понятный и логичный графический интерфейс, и мощнейшую систему фильтров. Во время подключения к удаленному рабочему столу программа замеряла отправленные и поступившие пакеты данных. Эти пакеты были отфильтрованы по IP-адресу сервера, а также по протоколу RDP. Интерфейс программы представлен на рисунке 8. График ввода/вывода данных по IP-адресу сервера по протоколу RDP представлен на рисунке 9. На графике на рисунке 9 видно два "всплеска" данных, т.е. две сессии подключения к серверу. Во время первой сессии проводилась работа с тяжеловесным графическим приложением. Во время второй сессии было включено видео, затем производился web-серфинг в браузере машины с некоторыми графическими материалами на странице. Как видно по графику, в пиковый момент была передача данных 5.5 Мбит/с. В последние моменты web-серфинга 0,65 Мбит/с. Таким образом можем сделать вывод, что протокол RDP не укладывается в ранее заявленный диапазон до 128 Кбит/с. Однако стоит учитывать, что RDP-сессия изначально очень требовательна к сети и является, по сути, передачей видеотрафика. Общедоступной информации в сети для анализа влияния облачной инфраструктуры на сеть, по крайней мере в русскоязычном сегменте интернета, чрезвычайно мало. Исследований по теме облачных вычислений недостаточно для заключения результата, и, в основном, это анализы финансовых затрат или производительности серверов. Наиболее подходящей темой для дискуссий на тему влияния облачной инфраструктуры на сеть могут служить только качество обслуживания (QoS) и договор о предоставлении услуг SLA, но данные темы слишком обширны и требует более углубленного внимания, а вопросы, связанные с ними, требуют внимания соответствующих специалистов.
img
Сегодня в статье рассказываем про инструменты с открытым исходным кодом, которые позволяют вам проверить скорость вашего Интернета и пропускную способность в Linux. Speedtest Speedtest - старый фаворит. Это инструмент для проверки скорости загрузки и скачивания с использованием speedtest.net. Он реализован на Python, упакован в Apt, а также доступен с pip. Вы можете использовать его как инструмент командной строки или в скрипте Python. Установите его с помощью: sudo apt install speedtest-cli Или: sudo pip3 install speedtest-cli Затем запустите его с помощью команды speedtest: speedtest Retrieving speedtest.net configuration... Testing from CenturyLink (65.128.194.58)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by CenturyLink (Cambridge, UK) [20.49 km]: 31.566 ms Testing download speed................................................................................ Download: 68.62 Mbit/s Testing upload speed...................................................................................................... Upload: 10.93 Mbit/s Это быстрая, и пригодная для скриптов утилита, поэтому вы можете запускать его регулярно и сохранять результаты в файл или базу данных для записи скорости вашей сети с течением времени. Fast Fast - это услуга, предоставляемая Netflix. Его веб-интерфейс расположен на Fast.com, а интерфейс командной строки доступен через npm: npm install --global fast-cli И веб-сайт, и утилита командной строки предоставляют один и тот же базовый интерфейс - это простой тест скорости, и ничего лишнего: fast 82 Mbps v Команда показывает вашу скорость скачивания (download) через Интернет. Чтобы получить скорость загрузки (upload), используйте флаг -u: fast -u ? 80 Mbps v / 8.2 Mbps ^ iPerf iPerf (iPerf3) - отличный способ проверить скорость вашей локальной сети (а не скорость Интернета, как это делают два предыдущих инструмента). Пользователи Debian, Raspbian и Ubuntu могут установить его с помощью apt: sudo apt install iperf [Debian/Ubuntu] yum install epel-release [RHEL/CentOS] yum install iperf3 [RHEL/CentOS] iPerf также доступен в Window и Mac После установки вам понадобятся два компьютера в одной сети, чтобы использовать его (на обоих должен быть установлен iPerf). Один мы будем использовать в качестве сервера. Узнайте IP-адрес сервера: ip addr show | grep inet.*brd Запустите iperf на сервере: iperf -s Это компьютер входящих соединений от клиентов. Теперь запустите на втором компьютере iperf с флагом -c и укажите ip-адрес сервера. iperf -c server_address NetHogs NetHogs это утилита для проверки полосы пропускания, который группирует информацию по процессам. Это может быть полезно, чтобы понять кто занимает всю полосу пропускания. NetHogs входит во многие дистрибутивы. Для его установки используйте: yum install epel-release [RHEL/CentOS] yum install nethogs [RHEL/CentOS] apt install nethogs [Debian/Ubuntu] Для запуска используйте: sudo nethogs Вы можете указать определенный интерфейс после команды: sudo nethogs eth0 Также у команды есть дополнительные параметры, такие как выбор задержки для частоты обновления -d, информации о версии -V, tracemode -t. nload nload позволяет отслеживать сетевой трафик и использование полосы пропускания в режиме реального времени, с большим количеством дополнительной информации, такой как: общий объем передаваемых данных, минимальное и максимальное использование сети и многое другое. Также nload строит графики входящего и исходящего трафика. Опции nload: device - выбор интерфейса -a - промежуток в секундах, для подсчитывания среднего значения -i - стопроцентная планка на графике пропускной способности в kBit/s -m - отображение нескольких интерфейсов, без графика -t - интервал обновления в миллисекундах -u - режим отображения: Bit/s, kBit/s, MBit/s Для установки используйте: sudo apt install nload [Debian/Ubuntu] yum install epel-release [RHEL/CentOS] um install nload [RHEL/CentOS] Для запуска: nload CBM – Color Bandwidth Meter CBM - очень простой инструмент, который отображает сетевой трафик на всех подключенных устройствах. Удобство заключается в том, что команды отображаются в нижней части терминала. Для установки используйте команду: sudo apt install cbm -y [Debian/Ubuntu] yum install epel-release [RHEL/CentOS] yum install cbm [RHEL/CentOS] После этого просто запустите: cbm vnStat vnStat - это монитор сетевого трафика, который использует статистику сетевого интерфейса, предоставляемую ядром, что означает что он не будет перехватывать трафик и в результате гарантирует низкую загрузку ЦПУ. Особенность vnStst в том, что он сохраняет все данные в собственной базе. vnStat также предоставляет веб-интерфейс на основе php для отображения графической статистики. Для настройки веб-интерфейса vnStat в вашей системе должны быть установлены пакеты Apache, php и php-gd. Для установки используйте команду: sudo apt install vnstat [Debian/Ubuntu] sudo yum install epel-release [RHEL/CentOS] sudo yum install vnstat [RHEL/CentOS] Для запуска: vnstat iftop iftop - это инструмент для мониторинга, который создает обновляемый список сетевых подключений между парами хостов в реальном времени. Для установки используйте: sudo apt install iftop [Debian/Ubuntu] yum install epel-release[RHEL/CentOS] yum install iftop [RHEL/CentOS] Для запуска: sudo iftop Будет произведен запуск с мониторингом всех интерфейсов. slurm slurm - это еще один инструмент мониторинга сетевой нагрузки для linux, который показывает результаты в графике ascii. Команды для установки: sudo apt-get install slurm [Debian/Ubuntu] sudo yum install slurm -y [RHEL/CentOS]
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59