По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Добро пожаловать в статью, посвященную началу работы с виртуализацией Xen на CentOS. Xen - это гипервизор с открытым исходным кодом, позволяющий параллельно запускать различные операционные системы на одной хост-машине. Этот тип гипервизора обычно называют гипервизором №1 в мире виртуализации.
Xen используется в качестве основы для виртуализации серверов, виртуализации настольных ПК, инфраструктуры как услуги (IaaS) и встраиваемых/аппаратных устройств. Возможность работы нескольких гостевых виртуальных машин на физическом хосте может значительно повысить эффективность использования основного оборудования.
Передовые возможности Xen гипервизора
Xen не зависит от операционной системы – основным стеком управления (который называется domain 0 (домен 0)) может быть Linux, NetBSD, OpenSolaris и так далее.
Возможность изоляции драйвера - Xen может разрешить основному системному драйверу устройства работать внутри виртуальной машины. Виртуальная машина может быть перезагружена в случае отказа или сбоя драйвера без воздействия на остальную часть системы.
Поддержка паравиртуализации (Paravirtualization - это тип виртуализации, в котором гостевая операционная система перекомпилируется, устанавливается внутри виртуальной машины и управляется поверх программы гипервизора, работающей на ОС хоста.): это позволяет полностью паравиртуализированным хостам работать гораздо быстрее по сравнению с полностью виртуализированным гостем, использующим аппаратные расширения виртуализации (HVM).
Небольшие размеры и интерфейс. В гипервизоре Xen используется микроядерное устройство, размер которого составляет около 1 МБ. Этот небольшой объем памяти и ограниченный интерфейс гостя делают Xen более надежным и безопасным, чем другие гипервизоры.
Пакеты Xen Project
Пакеты Xen Project состоят из:
Ядро Linux с поддержкой Xen Project
Сам гипервизор Xen
Модифицированная версия QEMU - поддержка HVM
Набор пользовательских инструментов
Компоненты Xen
Гипервизор Xen Project отвечает за обработку процессора, памяти и прерываний, поскольку он работает непосредственно на оборудовании. Он запускается сразу после выхода из загрузчика. Домен/гость - это запущенный экземпляр виртуальной машины.
Ниже приведен список компонентов Xen Project:
Гипервизор Xen Project работает непосредственно на оборудовании. Гипервизор отвечает за управление памятью, процессором и прерываниями. Он не знает о функциях ввода-вывода, таких как работа в сети и хранение.
Область контроля (Домен 0): Domain0 - специальная область, которая содержит драйверы для всех устройств в хост-системе и стеке контроля. Драйверы управляют жизненным циклом виртуальной машины - созданием, разрушением и конфигурацией.
Гостевые домены/виртуальные машины - гостевая операционная система, работающая в виртуализированной среде. Существует два режима виртуализации, поддерживаемых гипервизором Xen:
Паравиртуализация (PV)
Аппаратная поддержка или полная виртуализация (HVM)
Toolstack и консоль: Toolstack - это стек управления, в котором Domain 0 позволяет пользователю управлять созданием, конфигурацией и уничтожением виртуальных машин. Он предоставляет интерфейс, который можно использовать в консоли командной строки. На графическом интерфейсе или с помощью стека облачной оркестрации, такого как OpenStack или CloudStack. Консоль - это интерфейс к внешнему миру.
PV против HVM
Паравиртуализация (PV - Paravirtualization )
Эффективная и легкая технология виртуализации, которая была первоначально представлена Xen Project.
Гипервизор предоставляет API, используемый ОС гостевой виртуальной машины
Гостевая ОС должна быть изменена для предоставления API
Не требует расширений виртуализации от центрального процессора хоста.
Гостям PV и доменам управления требуется ядро с поддержкой PV и драйверы PV, чтобы гости могли знать о гипервизоре и могли эффективно работать без эмуляции или виртуального эмулируемого оборудования.
Функции, реализованные в системе Paravirtualization, включают:
Сигнал прерывания и таймеры
Драйверы дисков и сетевые драйверы
Эмулированная системная плата и наследуемый вариант загрузки (Legacy Boot)
Привилегированные инструкции и таблицы страниц
Аппаратная виртуализация (HVM - Hardware-assisted virtualization ) - полная виртуализация
Использует расширения виртуальной машины ЦП от ЦП хоста для обработки гостевых запросов.
Требуются аппаратные расширения Intel VT или AMD-V.
Полностью виртуализированные гости не требуют поддержки ядра. Следовательно, операционные системы Windows могут использоваться в качестве гостя Xen Project HVM.
Программное обеспечение Xen Project использует Qemu для эмуляции аппаратного обеспечения ПК, включая BIOS, контроллер диска IDE, графический адаптер VGA, контроллер USB, сетевой адаптер и так далее
Производительность эмуляции повышается за счет использования аппаратных расширений.
С точки зрения производительности, полностью виртуализированные гости обычно медленнее, чем паравиртуализированные гости, из-за необходимой эмуляции.
Обратите внимание, что можно использовать PV драйверы для ввода-вывода, чтобы ускорить гостевой HVM
Драйверы PVHVM - PV-on-HVM
Режим PVH сочетает в себе лучшие элементы HVM и PV
Позволяет виртуализированным аппаратным гостям использовать PV диск и драйверы ввода-вывода
Никаких изменений в гостевой ОС
Гости HVM используют оптимизированные драйверы PV для повышения производительности - обходят эмуляцию дискового и сетевого ввода-вывода, что приводит к повышению производительности в системах HVM.
Оптимальная производительность на гостевых операционных системах, таких как Windows.
Драйверы PVHVM требуются только для гостевых виртуальных машин HVM (полностью виртуализированных).
Установка Xen в CentOS 7.x
Чтобы установить среду Xen Hypervisor, выполните следующие действия.
1) Включите репозиторий CentOS Xen
sudo yum -y install centos-release-xen
2) Обновите ядро и установите Xen:
sudo yum -y update kernel && sudo yum -y install xen
3) Настройте GRUB для запуска Xen Project.
Поскольку гипервизор запускается перед запуском ОС, необходимо изменить способ настройки процесса загрузки системы:
sudo vi /etc/default/grub
Измените объем памяти для Domain0, чтобы он соответствовал выделенной памяти.
RUB_CMDLINE_XEN_DEFAULT="dom0_mem=2048M,max:4096M cpuinfo com1=115200,8n1 console=com1,tty loglvl=all guest_loglvl=all"
4) Запустите скрипт grub-bootxen.sh, чтобы убедиться, что grub обновлен /boot/grub2/grub.cfg
bash `which grub-bootxen.sh`
Подтвердите изменение значений:
grep dom0_mem /boot/grub2/grub.cfg
5) Перезагрузите свой сервер
sudo systemctl reboot
6) После перезагрузки убедитесь, что новое ядро работает:
# uname -r
7) Убедитесь, что Xen работает:
# xl info
host : xen.example.com
release : 3.18.21-17.el7.x86_64
machine : x86_64
nr_cpus : 6
max_cpu_id : 5
nr_nodes : 1
cores_per_socket : 1
threads_per_core : 1
.........................................................................
Развертывание первой виртуальной машины
На этом этапе вы должны быть готовы к началу работы с первой виртуальной машиной. В этой демонстрации мы используем virt-install для развертывания виртуальной машины на Xen.
sudo yum --enablerepo=centos-virt-xen -y install libvirt libvirt-daemon-xen virt-install
sudo systemctl enable libvirtd
sudo systemctl start libvirtd
Установка HostOS в Xen называется Dom0. Виртуальные машины, работающие через Xen, называются DomU.
virt-install -d
--connect xen:///
--name testvm
--os-type linux
--os-variant rhel7
--vcpus=1
--paravirt
--ram 1024
--disk /var/lib/libvirt/images/testvm.img,size=10
--nographics -l "http://192.168.122.1/centos/7.2/os/x86_64"
--extra-args="text console=com1 utf8 console=hvc0"
Если вы хотите управлять виртуальными машинами DomU с помощью графического приложения, попробуйте установить virt-manager
sudo yum -y install virt-manager
Интернет может быть опасным. Спросите любого хорошего IT-специалиста, и он вам обязательно расскажет о важности обеспечения безопасности и компактности систем, чтобы можно было гарантировать, что новые системы смогут безопасно предоставлять требуемые услуги. И хотя автоматизация этого процесса имеет большое значение для сокращения времени адаптации, настоящим испытанием для системы является способность предоставлять услуги стабильно и без каких-либо пауз на постоянной основе.
Существуют автоматизированные средства, которые могут гарантировать, то ваши сервисы Windows будут такими же безопасными и будут безотказно работать также, как и в день их установки. Однако, поскольку все организации имеют разные потребности и разные бюджеты, то для них некоторые инструменты могут быть недоступны, например, такие как Microsoft System Center Configuration Manager. Но это не должно мешать IT-отделу использовать свою инфраструктуру для обеспечения правильной работы систем.
Ниже приведены несколько принципов управления, которые можно легко реализовать при любом уровне квалификации и любом бюджете, чтобы помочь вашему IT-отделу контролировать свои серверы Windows и убедиться, что они управляются эффективно и безопасно, а также что они оптимизированы для обеспечения максимально возможной производительности.
Аудит политики авторизации
Все серверы должны быть закрыты для всех локальных и интерактивных входов в систему. Это означает, что никто не должен входить на сервер физически и использовать его, как если бы это был рабочий стол, независимо от его уровня доступа. Такое поведение в какой-то момент в будущем может привести к катастрофе. Помимо контроля интерактивных входов в систему, IT-отдел должен иметь политику аудита и других типов доступа к своим серверам, включая, помимо прочего, доступ к объектам, права доступа и другие изменения, которые могут быть внесены в сервер с авторизаций и без нее.
Централизация журналов событий
Серверы Windows имеет множество возможностей ведения журналов, которые доступны по умолчанию. Существуют настройки, с помощью которых можно расширить или ограничить эти возможности ведения журналов, включая увеличение размеров файлов журналов, независимо от того, перезаписываются ли они или нет, даже в, казалось бы, свойственных для них моментах. Централизация всех этих различных журналов в одном месте упрощает доступ к ним и их просмотр для IT-персонала. Можно воспользоваться каким-либо сервером системных журналов и упростить эти журналы, обозначив категории для определенных записей, например, пометить все неудачные попытки авторизации. Также полезным может быть доступность поиска по журналу и возможность для сервера системного журнала иметь интеграцию с инструментами исправления для устранения любых обнаруженных проблем.
Контрольные и базовые показатели производительности
Мы все знаем, как определить, когда сервер или сервис совсем не работают. Но как ваш IT-отдел определяет, работает ли сервер или сервис должным образом? Вот почему полезно получить контрольные показатели ваших серверов и определить базовые показатели их работы с различными интервалами (пиковые и непиковые). Имея такую информацию, можно определить, как оптимизировать параметры программного и аппаратного обеспечения, как это влияет на работу сервисов в течение дня и какие ресурсы нужно добавить, удалить или просто переместить, чтобы обеспечить минимальный уровень обслуживания. Это также помогает определить вероятное направление атак или индикаторы компрометации при обнаружении аномалий, которые могут негативно отразиться на производительности.
Ограничение удаленного доступа
Как администраторы, все мы любим удаленный доступ, не так ли? Я это знаю, поскольку сам почти каждый день использовал протокол удаленного рабочего стола (RDP – remote desktop protocol) для устранения проблем в удаленных системах на протяжении десятков лет своей карьеры. И несмотря на то, что был пройден долгий путь по усилению безопасности за счет усиленного шифрования, факт остается фактом: RDP (как и любые другие приложения удаленного доступа), если их не контролировать, могут позволить злоумышленникам проникнуть на ваши серверы и, что еще хуже, на сеть компании. К счастью, доступ к серверам можно ограничить несколькими способами, например, настроить правила брандмауэра для ограничения доступа к серверам из удаленных подключений, установить требования для использования VPN-туннелирования для защиты связи между сетевыми ресурсами или настроить проверку подлинности на основе сертификатов с целью проверки того, что подключаемая система – как к, так и от – отвергнута или ей можно доверять.
Настройка сервисов
Прошло уже много времени с тех пор, как большинство ролей и сервисов были включены в Windows Server по умолчанию, независимо от того, нужны они организации или нет. Это, очевидно, представляет собой грубейшую ошибку безопасности и до сих пор остается проблемой, хотя и более контролируемой в современных версиях серверов. Тем не менее, ограничение поверхности атаки ваших серверов служит для устранения потенциальных направлений компрометации, и это хорошо. Оцените потребности вашей среды и зависимостей программного обеспечения и сервисов. Это может помочь разработать план по отключению или удалению ненужных сервисов.
Периодический контроль
Периодический контроль тесно связан с вашей сетью и угрозами безопасности. Вы должны следить за состоянием своего сервера, чтобы выявлять любые потенциальные проблемы до того, как они перерастут в серьезную угрозу для производительности устройств и услуг, которые они предоставляют. Такой контроль помогает IT-специалистам заранее определять, нуждаются ли какие-либо серверы в обновлении или ресурсах, или же отдел должен приобрести дополнительные серверы для добавления в кластер, чтобы, опять же, поддерживать работу сервисов.
Управление Patch-файлами
Эта рекомендация должна быть элементарной для всех, кто занимается IT, независимо от опыта и навыков. Если в этом списке и есть что-то, что нужно всем серверам, так это именно управление patch-файлами, или исправлениями. Настройка процесса обновления операционной системы и программного обеспечения имеет первостепенное значение, от простых обновлений, устраняющих ошибки, до корректирующих исправлений, закрывающих бреши в безопасности. Это на самом деле важно, поскольку в интегрированных средах, где используется несколько продуктов Microsoft, некоторые версии ПО и сервисов просто не будут работать до тех пор, пока базовая ОС Windows Server не будет обновлена до минимального уровня. Так что, имейте это в виду, когда будете планировать цикл тестирования и обновлений.
Технические средства контроля
Независимо от того, внедряете ли вы устройства безопасности, такие как система предотвращения вторжений в сеть, или вашим кластерным серверам нужны балансировщики нагрузки, используйте данные, полученные в ходе мониторинга, и базовые показатели для оценки потребностей различных серверов и предоставляемых ими услуг. Это поможет определить, какие системы требуют дополнительных элементов управления, таких как веб-сервер, на котором будет запущено корпоративное веб-приложение для HR-записи. Установка брандмауэра веб-доступа (WAF – web access firewall) предназначена для выявления известных веб-атак, таких как межсайтовый скриптинг (XSS-атаки) или атаки с использованием структурированного языка запросов (SQL-инъекции) на серверную часть базы данных SQL, которая обеспечивает ее работу.
Блокировка физического доступа
По личному опыту знаю, что большинство организаций, от средних до крупных, осознают, что свои серверы необходимо изолировать из соображений безопасности и ОВК. И это здорово! Однако нехорошо получается, когда небольшие компании просто оставляют свои серверы открытыми вместе с обычными рабочими столами. Это действительно ужасно, потому что в таком случае сервер и связи со сторонними устройствами могут быть подвержены множеству потенциальных атак и угроз. Большая просьба – размещайте серверы в хорошо охраняемых помещениях с достаточной вентиляцией и ограничьте доступ в это помещение, разрешите его только тем, кому это действительно необходимо.
Аварийное восстановление
Резервные копии… резервные копии… резервные копии! Эта тема уже настолько избита, но все же мы здесь. Мы по-прежнему знаем, что некоторые организации не принимают никаких надлежащих шагов для правильного и безопасного резервного копирования своих ценных данных. А когда происходит неизбежное – сервер падает, данные теряются, а помочь некому. Но помочь можно было бы, если бы существовал план аварийного восстановления, который бы определял, какие данные нужно защитить, как, когда и где следует создавать резервные копии, а также документированные шаги по их восстановлению. По сути это очень простой процесс: 3-2-1 – три резервные копии, два отдельных носителя и, по крайней мере, одна копия за пределами рабочего места.
Этот список ни в коем случае не позиционируется как исчерпывающий, и IT-специалисты должны самостоятельно изучить каждый пункт, чтобы определить, какие решения лучше всего подходят для их конкретных потребностей. Помимо этого, крайне желательно, чтобы IT-отдел советовался с высшим руководством по разработке политики проведения регулярных оценок рисков. Это поможет IT-отделу определить, где лучше всего размещать ресурсы (финансовые, технические и аппаратное/программное обеспечение), чтобы они использовались максимально эффективно.
Дорогой друг! Ранее мы рассказывали про новинки FreePBX 14. Новые и интересные фичи безусловно не будут лишними. Ну что же, приступим теперь к обновлению FreePBX 13 версии до 14?
Pre-work
Рекомендуем перед началом работ сделать полный бэкап/снэпшот сервера, на котором будут производиться работы;
Как и у любого пользователя FreePBX, у вас в Dashboard графической оболочки появилось следующее уведомление:
Заманчивое название модуля. Переходим в консоль (подключаемся пол SSH) вашего сервера и даем простую команду:
fwconsole ma downloadinstall versionupgrade
Модуль будет установлен:
Теперь возвращаемся в FreePBX. В правом верхнем углу нажимаем Apply Config. Далее, прыгаем по пути Admin → 13 to 14 Upgrade Tool и вот что мы увидим:
Нажимаем на кнопку Check the requirements! и смотрим: система говорит, что у нас установлен FreePBX Distro и нам необходимо воспользоваться специальным скриптом для апгрейда. Что же, приступим к обновлению вручную.
Обновление через CLI
Перед началом работ есть определенные требования, такие как:
Сервер с 64 - битной архитектурой;
Как минимум 10 Гб свободного места;
Стабильное интернет соединение;
Если вы используете 32 – битную архитектуру, то проще всего воспользоваться FreePBX Conversion tool, сделав бэкап на 32 – битной системе, а восстановить его в системе 64 – бит с FreePBX 14. При попытке установки на 32 – битной системе процесс предупредит вас об этом:
Устанавливаем нужный RPM:
yum -y install http://package1.sangoma.net/distro-upgrade-1707-16.sng7.noarch.rpm
После успешной установки RPM даем следующую команду:
distro-upgrade
И переходим в интерактивный режим:
[root@freepbx ~]# distro-upgrade
??????????????????????????????????????????????
? ?
? Sangoma 6 to 7 Upgrade Tool ?
? ?
? Distro Upgrade - Version 1707-2.sng7 ?
? Build Date: 2017-06-21 ?
? ?
??????????????????????????????????????????????
Checking prerequsites...
Checking bitsize of machine [ ? ] - x86_64
Checking available disk space [ ? ] - 13G Available
All prerequsites passed!
Are you ready to upgrade your machine to SNG7? This process requires
two reboots, and will download approximately 200mb of files before
starting. There will be no interruption to service until this machine
is rebooted.
Download files required for upgrade [Yn]?
Указываем y:
Download files required for upgrade [Yn]? y
######### Starting setup upgrade on Tue Aug 22 17:39:08 MSK 2017 #########
######### Creating upgrade repofile #########
######### Installing needed packages #########
######### Running preupgrade #########
######### Running upgrade-tool #########
######### Downloading sangoma-release rpm #########
######### Updating packages.list #########
######### Verified sangoma-release in package.list #########
######### Reboot to finish this stage of the upgrade #########
######### Finished setup upgrade on Tue Aug 22 17:44:12 MSK 2017 #########
Preparations complete!
Please reboot your machine when convenient. This machine will install all the new
and upgraded packages, and then reboot for a second time automatically. After the
second reboot, it will then continue the upgrade process automatically. When the
upgrade is complete, you will be presented with a standard login prompt.
Важно! Данный процесс можно проводить в рабочее время параллельно с обслуживанием вызовов. Даунтайм подразумевается только далее, после перезагрузки.
Перезагружаем сервер командой reboot. При загрузке, у вас будет автоматически выбрана опция System Upgrade, как показано ниже. Если нет, то выберите эту опцию вручную стрелками на клавиатуре:
После этого начнется процесс обновления. Длительность этого процесса напрямую коррелирует с производительностью вашего сервера. После обновление компоненты Core OS произойдет вторая перезагрузка, в рамках которой произойдет обновление всех модулей FreePBX, после чего апгрейд будет завершен.
По окончанию, вы увидите стандартный баннер FreePBX 14:
Выполняем проверку версии. Даем команду в консоль:
ls -l /usr/src | grep freepbx
Если все ОК, то вывод будет вот такой: