По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В этом руководстве мы расскажем, как установить KVM и как его использовать, чтобы создать виртуальные машины с такими дистрибутивами как RHEL, CentOS 7 и Fedora 21, основанными на RedHat.
Что такое KVM?
KVM (Kernel-based Virtual Machine) – это решение для полной виртуализации для Linux на оборудовании Intel 64 и AMD 64, которое включено в основное ядро Linux, начиная с версии 2.6.20. Аппаратные средства работают быстро и стабильно даже при больших нагрузках.
Функции KVM
KVM обладает большим количеством преимуществ и полезных функций, которые окажутся в Вашем распоряжении, если для установки виртуальной платформы Вы выберете данное программное обеспечение.
Гипервизор KVM поддерживает следующие функции:
Over-committing – с помощью этой функции можно обеспечить направление большего количества средств центрального процессора и памяти, чем доступно в системе.
Thin provisioning – функция позволяет выделить гибкое хранилище и оптимизирует доступное пространство для каждой гостевой виртуальной машины.
Disk I/O throttling – функция предоставляет возможность установить ограничение на запросы ввода-вывода диска, отправляемые с виртуальных машин на хост.
Automatic NUMA balancing – функция улучшает работу приложений на аппаратных решениях NUMA.
Virtual CPU hot add capability – данная функция предоставляет возможность увеличить процессорную память настолько, насколько это нужно работающей ВМ без простоев.
Подготовительная работа
Убедитесь, что Ваша система имеет расширение аппаратной виртуализации. Для хостов на базе Intel ЦП должен поддерживать расширение виртуализации [vmx]. Чтобы проверить наличие расширения, используйте следующую команду:
# grep -e 'vmx' /proc/cpuinfo
Для хостов на базе AMD ЦП поддерживает расширение виртуализации [svm]:
# grep -e 'svm' /proc/cpuinfo
Если вывод отсутствует, убедитесь, что в BIOS включена опция расширения виртуализации. Убедитесь, что модули KVM загружены в ядро (это должно быть загружено по умолчанию).
# lsmod | grep kvm
Вывод должен содержать kvm_intel для хостов на базе Intel и kvm_amd – на базе AMD.
Вам также потребуются доступ уровня root или пользователь с sudo привилегиями, настроенными на Вашу систему. Также убедитесь, что Ваша система обновлена.
# yum update
Убедитесь, что Selinux в режиме Permissive.
# setenforce 0
Шаг 1: Установка KVM
Сначала мы установим пакеты qemu-kvm и qemu-img. Эти пакеты предоставляют KVM и image manager доступ на уровне пользователя.
# yum install qemu-kvm qemu-img
Теперь у Вас есть минимум требований, чтобы установить виртуальную платформу на вашем хосте. Но есть ещё полезные приложения, которые помогают в администрировании платформой:
virt-manager (менеджер управления виртуальными машинами) предоставляет GUI-конструктор для управления виртуальными машинами.
libvirt-client предоставляет инструмент CL для управления вашей виртуальной средой. Такая утилита называется virsh.
С помощью команды virt-install, которую предоставляет программа virt-install, Вы можете создать виртуальную машину, используя CLI (интерфейс командной строки).
С помощью библиотеки libvirt сервер и хост могут взаимодействовать с гипервизорами и хост-системами.
Давайте установим эти инструменты с помощью следующей команды:
# yum install virt-manager libvirt libvirt-python libvirt-client
Для пользователей RHEL/CentOS7 также есть дополнительные группы пакетов, которые можно установить, например: Virtualization Client, Virtualization Platform и Virtualization Tools
#yum groupinstall virtualization-client virtualization-platform virtualization-tools
Демоном виртуализации, который управляет платформой, является libvirtd. Давайте перезапустим его.
#systemctl restart libvirtd
После того, как Вы перезапустили демона, проверьте его статус с помощью следующей команды:
#systemctl status libvirtd
Пример вывода
libvirtd.service - Virtualization daemon
Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled)
Active: active (running) since Mon 2014-12-29 15:48:46 EET; 14s ago
Main PID: 25701 (libvirtd)
Теперь давайте перейдем к следующему разделу и создадим виртуальную машину.
Шаг 2: Создание ВМ с помощью KVM
Так как мы установили несколько полезных приложений для управления виртуальными платформами и создания виртуальных машин, одно из них –virt-manager – нам сейчас понадобится.
Несмотря на то, что virt-manager является инструментом, основанным на графическом интерфейсе пользователя, из терминала мы можем запускать его так же, как и из GUI.
#virt-manager
GNOME
GNOME Classic
После того, как Вы запустите приложение, появится такое окно.
По умолчанию менеджер напрямую подключен к localhost. Но Вы можете использовать тот же инструмент, чтобы выбрать другой хост удаленно. Из вкладки File выберите Add Connection и появится следующее окно.
Поставьте галочку на Connect to remote host и впишите название или IP (Hostname) удаленного сервера. Если Вам нужно устанавливать соединение с удаленным сервером каждый раз, когда запускается менеджер, то поставьте галочку на Auto Connect.
Давайте вернемся к localhost. Прежде чем создавать виртуальную машину, Вы должны решить, где будут храниться файлы. Другими словами, Вам необходимо создать том (виртуальный диск) для вашей виртуальной машины. Правой кнопкой мыши нажмите на localhost и выберите Details, а затем перейдите на вкладку Storage.
Затем нажмите кнопку New Volume (Новый том) и введите название вашего нового виртуального диска (тома). В графу Max Capacity (Максимальная ёмкость) введите требующийся вам объем диска.
Выбранный объем является реальным объемом Вашего диска, который сразу будет предоставлен с Вашего физического диска после завершения установки.
Примечание: технология в области администрирования хранилищ называется thin provision (Тонкое обеспечение). Она используется для выделения только используемого объема хранилища, а не всего доступного объема. Например, Вы создали виртуальный диск размером 60 Гб, но используемого объема у Вас только 20 Гб. С помощью данной технологии жёсткий диск предоставит Вам только 20 Гб, а не 60.
Другими словами, выделенный физический объем будет динамически распределяться в зависимости от фактического используемого объема.
Знак нового диска появится в списке.
Найти Ваш новый виртуальный диск Вы сможете по умолчанию с помощью команды /var/lib/libvirt/images.
# ls -l /var/lib/libvirt/images
-rw-------. 1 root root 10737418240 Jan 3 16:47 vm1Storage.img
Наконец, мы готовы к созданию виртуальной машины. Нажмите на кнопку VM на главном экране, и появится окно.
Выберите метод установки для создания ВМ. Мы пока выберем Local install media, а позже обсудим оставшиеся методы.
Теперь мы должны выбрать, какой локальный носитель использовать. У нас есть два варианта:
Физический CDROM/DVD
ISO-образ
Давайте выберем ISO-образ и введем его путь.
Важно: к сожалению, для тех, кто использует RHEL или CentOS7, здесь есть баг. Он не даёт установить машину с использованием физического носителя CDROM/DVD. Опция просто будет серая:
И если Вы наведете курсор, то появится сообщение об ошибке: physical cdrom passthrough not supported with this hypervisor (Физический CDROM не поддерживает данный гипервайзер).
Больше информации можете узнать здесь.
Снова вопрос про хранилище. Используем виртуальный диск, который мы недавно создали. Он скоро появится.
На последнем шаге Вам необходимо дать название виртуальной машине.
Если Вы хотите изменить что-то в конфигурации или сделать небольшую адаптацию, поставьте галочку на Customize configuration before install. Затем нажмите на finish и подождите несколько секунд, пока не появится контрольная консоль для вашей гостевой ОС.
Готово!
Заключение
Вы узнали, что такое KVM, как управлять виртуальной платформой с помощью инструментов GUI, как создать виртуальную машину с помощью этого приложения и много других классных штук.
Сегодня мы расскажем про то, как обновить IOS на устройствах Cisco. Новые версии IOS выходят постоянно и в них добавляют новый функционал, исправляют уязвимости и баги, поэтому важно иметь обновленное устройство.
Обновление
Начнем с того, что посмотрим, какая версия IOS установлена на данный момент, используя команду show version
Router#show version
Cisco IOS Software, 2800 Software (C2800NM-ADVIPSERVICESK9-M), Version 12.4(15)T1, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2007 by Cisco Systems, Inc.
Compiled Wed 18-Jul-07 06:21 by pt_rel_team
ROM: System Bootstrap, Version 12.1(3r)T2, RELEASE SOFTWARE (fc1)
Copyright (c) 2000 by cisco Systems, Inc.
Из вывода этой команды мы видим, что текущая версия прошивки – 12.4.(15)T1. Подробнее о версиях IOS можно прочесть в этой статье.
Далее найдем новую версию прошивки для нашего маршрутизатора на сайте cisco.com и скачаем её.
Затем посмотрим доступный объем flash памяти, где находится текущий файл IOS, при помощи команды show flash.
Router#show flash
System flash directory:
File Length Name/status
3 50938004 c2800nm-advipservicesk9-mz.124-15.T1.bin
2 28282 sigdef-category.xml
1 227537 sigdef-default.xml
[51193823 bytes used, 12822561 available, 64016384 total]
63488K bytes of processor board System flash (Read/Write)
Тут мы видим, что текущий файл IOS - c2800nm-advipservicesk9-mz.124-15.T1.bin занимает 50 мегабайт из доступных 64, и у нас остается свободно 12 мегабайт flash памяти. Чтобы загрузить новую версию прошивки нам не хватает места, поэтому нужно удалить старую. Используем команду delete /force /recursive flash:имя_файла.
Router# delete /force /recursive flash:c2800nm-advipservicesk9-mz.124-15.T1.bin
Теперь поместим скачанную версию IOS на TFTP или FTP сервере и с него скачаем себе на роутер. Для этого сначала используем команду copy [откуда] [куда] . Потом указываем IP адрес нашего TFTP сервера, имя файла и какое он будет иметь название после копирования.
Router#copy tftp: flash:
>Address or name of remote host []? 192.168.1.2
>Source filename []? c2800nm-advipservicesk9-mz.151-4.m12a.bin
>Destination filename [c2800nm-advipservicesk9-mz.151-4.m12a.bin]?
Accessing tftp://192.168.1.2/ c2800nm-advipservicesk9-mz.151-4.m12a.bin…
Loading c2800nm-advipservicesk9-mz.151-4.m12a.bin from 192.168.1.2 (via FastEthernet0/0):
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Проверить содержимое памяти можно используя команду dir flash
Router#dir flash
Directory of flash:/
3 -rw- 50938004 c2800nm-advipservicesk9-mz.151-4.m12a.bin
2 -rw- 28282 sigdef-category.xml
1 -rw- 227537 sigdef-default.xml
64016384 bytes total (58188981 bytes free)
Также можно проверить все ли в порядке с самим файлом, сравнив его MD5 сумму, с той, которая указана у этого файла на сайте Cisco.
Router#verify /md5 flash:c2800nm-adventerprisek9-mz.151-4.M12a.bin
.................Done!
verify /md5 (flash:c2800nm-adventerprisek9-mz.151-4.M12a.bin) = fcdaeb55b292534e97ecc29a394d35aa
Если на нашей flash памяти хранится больше одного образа IOS, то нужно вручную при помощи команды boot system указать какой будет загружаться.
Router(config)#boot system flash:c2800nm-adventerprisek9-mz.151-4.M12a.bin
Затем отправляем наше устройство в ребут командой reload, и при включении загрузится новая версия. Проверить это можно снова выполнив команду show version и найдя строчку System image file is.
System image file is "flash:c2800nm-adventerprisek9-mz.151-4.M12a.bin"
Если мы тут видим название файла образа новой IOS, то значит, что мы успешно обновились.
В обычной корпоративной сети доступ к серверам из филиалов организации может осуществляться, чаще всего, подключением к серверам, расположенным в центральном офисе. Но при расположении серверной инфраструктуры в облаке параметры связи рабочих станций с серверами будут зависеть уже не от канала связи от каждого конкретного филиала до центрального офиса, а от канала связи всех отделений организации с ЦОД облачного провайдера, чьими услугами пользуется организация для формирования облачной инфраструктуры.
Переход в облака поставил перед разработчиками ПО и сетевыми инженерами ряд новых условий, вызывающих задержку сигнала, которые им приходится учитывать для формирования качественного доступа к данным в облаке. Например, задержка длительностью 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, но данные темы слишком обширны и требует более углубленного внимания, а вопросы, связанные с ними, требуют внимания соответствующих специалистов.