По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В сегодняшней статье мы опишем процесс установки Proxmox Virtual Environment (VE) — систему управления виртуализации с открытым кодом, которая базируется на QEMU/KVM и LXC. Данное решение позволяет вам управлять виртуальными машинами, контейнерами, отказоустойчивыми кластерами, СХД и прочие — все это с помощью веб-интерфейса или CLI. Чтобы было понятнее — Proxmox VE это альтернатива c открытым программным кодом таким продуктам как VMware vSphere, Microsoft Hyper-V или Citrix XenServer.
Важное уточнение — согласно лицензии GNU AGPL v3 данное ПО является бесплатным, но, есть возможность купить подписку. Подписка дает следующие преимущества — поддержка от вендора/коммьюнити (в зависимости от выбранного плана), доступ к репозиторию и так далее. Скачать данную платформу можно по следующей ссылке: https://www.proxmox.com/en/downloads
Немного о системных требованиях — в идеале, требуется железный сервер, предпочтительно многопроцессорный и 8 Гб памяти для самого Proxmox и остальное — для гостевых машин + 2 сетевых карты.
В нашем примере мы установим Proxmox также на виртуальный сервер исключительно для демонстрации процесса установки, и выделили ему 1 Гб оперативной памяти. Список поддерживаемых браузеров включает Chrome, Mozilla Firefox, Safari и IE (актуальные версии).
Установка
Итак, вы скачали ISO-file по ссылке выше, запустили виртуальную машину и должны увидеть следующее:
Кликаем на Install Proxmox VE. После этого появится черный экран с различной информацией, затем (в моем случае, из-за установки на виртуальную машину) появиться предупреждение об отсутствии поддержки виртуализации, и, наконец, откроется окно с установкой и EULA:
Читаем, и, надеюсь, соглашаемся с лицензионным соглашением и кликаем Agree:
Затем, нам предлагают выбрать диск для установки — выбираем и кликаем Next:
Выбираем страну и часовой пояс и кликаем далее:
Затем придумываем сложный рутовый пароль и вводим действующий емейл — на него в случае чего будут сыпаться алерты:
Указываем настройки сети — выбираем адаптер, указываем хостнейм и так далее. В моем случае я только указал иной хостнейм. Кликаем Next:
Начинается процесс установки, который занимает не более 10 минут:
Установка заканчивается, и все, что нужно сделать — это нажать Reboot.
После перезагрузки скрипт попытается извлечь установочный ISO из виртуального дисковода, и, по каким-то неясным мне причинам, на виртуальной машине Hyper-V скрипт потерпел неудачу и данный шаг пришлось выполнять руками.
После перезагрузки вы увидите адрес, по которому нужно зайти в браузере для завершения установки. В данном случае это https://192.168.1.38:8006
Появляется окно логина, с возможностью выбрать язык. Вводите логин root и пароль, который вы указывали при установке:
И, наконец, системой можно пользоваться!
К примеру, можете кликнуть на вкладку Датацентр слева и увидеть сводку информации по системе:
Примеры использования
Первым делом попробуем создать виртуальную машину (и да, алерт касаемо отсутствия поддержки виртуализации все еще висит перед глазами, но все равно интересно!).
В правом верхнем углу кликаем на кнопку Создать VM:
Задаем имя, кликаем далее, указываем всю необходимую информацию и, в конце концов нас ожидает следующее:
Как и следовало ожидать, однако…
Теперь перейдем к созданию контейнера — для этого кликните в левом верхнем углу на ваш «датацентр», затем на первое «хранилище» - в данном случае это local (merionet).
Затем кликните на кнопку Шаблоны и скачайте один из шаблонов — я для этой цели выбрал простой Debian.
Начнется процесс скачивания, по завершению которого, можно будет закрыть данное диалоговое окно. Теперь нажимаем в левом верхнем углу Создать CT
На первой вкладке указываем его хостнейм и пароль и кликаем Далее.
На скриншоте выше видны сетевые настройки, выбранные мной для примера создания контейнера.
После чего проверяем настройки и нажимаем Завершить.
Начнется процесс создания контейнера, и нужно будет буквально несколько секунд подождать.
Затем вы можете кликнуть в левом верхнем углу на него и попробовать поделать различные манипуляции! На этом все, это была статья по установке Proxmox VE на виртуальную машину и максимально базовый обзор его возможностей. В будущем у нас появятся новые статьи на эту тему, с более подробным обзором функционала данного ПО.
Ядро Linux - это фундамент, на котором работают все дистрибутивы Linux. Это программное обеспечение с открытым исходным кодом - любой может декомпилировать, изучить и изменить код.
Обновленные версии ядра могут повысить безопасность, добавить функциональность и повысить скорость работы операционной системы.
Это руководство расскажет вам, как обновить ядро Linux на CentOS 7.
Шаги по обновлению версии ядра CentOS
Менеджер пакетов yum позволяет обновлять ядро. Однако CentOS не предлагает последнюю версию ядра в официальном репозитории.
Чтобы обновить ядро в CentOS, вам необходимо установить сторонний репозиторий под названием ElRepo. ElRepo предлагает последнюю версию ядра, доступную на kernel.org.
Официальные выпуски тестируются, чтобы убедиться, что они работают правильно и не дестабилизируют работу приложений и функций ОС. Есть два типа версий ядра Linux:
Стабильный выпуск ядра с долгосрочной поддержкой (Stable long-term supported kernel release) - обновляется реже, но поддерживается дольше.
Основной выпуск ядра (Mainline kernel release) - более короткий срок поддержки, но более частые обновления.
Шаг 1. Проверьте текущую версию ядра.
Чтобы проверить текущую версию ядра в CentOS, откройте интерфейс командной строки и введите следующую команду:
uname -msr
Система должна вернуться с записью, которая выглядит следующим образом:
Output
Linux 3.10.0-862.el7.x86-64 x86-64
В выходных данных указывается, какая версия ядра используется в настоящее время и на какой архитектуре оно основано.
Шаг 2. Обновите репозитории CentOS
Перед обновлением ядра все пакеты должны быть обновлены до последней версии.
Чтобы обновить репозитории программного обеспечения CentOS, используйте команду:
sudo yum -y update
Ваш репозиторий программного обеспечения обновлен. Это гарантирует, что у вас будет доступ к последней версии ядра.
Примечание. Параметр -y указывает системе отвечать «да» на любые всплывающие подсказки.
Шаг 3. Включите репозиторий ELRepo
Чтобы установить новую версию ядра, необходимо включить новый репозиторий (репозиторий ELRepo).
В окне терминала введите:
sudo rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
Предыдущая команда устанавливает ключ GPG для репозитория ELRepo. Это важно - CentOS не позволит установить неподписанный программный пакет. Ключ GPG обеспечивает цифровую подпись для проверки подлинности программного обеспечения.
Затем установите репозиторий ELRepo, выполнив следующую команду:
sudo rpm -Uvh https://www.elrepo.org/elrepo-release-7.0-3.el7.elrepo.noarch.rpm
Подождите, пока система завершит выполнение операции.
Шаг 4: Список доступных ядер
Чтобы вывести список доступных ядер, введите:
yum list available --disablerepo='*' --enablerepo=elrepo-kernel
Система должна вернуть список доступных модулей. Обратите внимание на строку в списке, в которой написано kernel-lt, что означает стабильный выпуск с долгосрочной поддержкой, или kernel-ml, который указывает на основной выпуск с более коротким сроком поддержки, но с более частыми обновлениями.
Затем посмотрите на правый столбец и обратите внимание на ряд букв и цифр (который выглядит примерно как «4.4.113-1.e17.elrepo»). Это версия ядра.
Используйте эти две части информации, чтобы решить, какую версию ядра вы хотите установить. Как видите, ядро Linux 5 - это последний основной выпуск.
Шаг 5: Установите новую версию ядра CentOS
Чтобы установить последнее основное ядро:
sudo yum --enablerepo=elrepo-kernel install kernel-ml
Чтобы установить последнее ядро долгосрочной поддержки:
sudo yum --enablerepo=elrepo-kernel install kernel-lt
Система должна загрузить программное обеспечение, а затем предложить вам подтвердить, что установка подходит - введите y и нажмите Enter.
Подождите, пока процесс завершится.
Шаг 6: перезагрузите и выберите новое ядро
Перезагрузите систему, выполнив команду:
reboot
Вам будет представлен GRUB или меню загрузки.
С помощью клавиш со стрелками выберите только что установленное ядро ??Linux, затем нажмите Enter. Ваша операционная система должна нормально загрузиться.
Шаг 7. Проверьте работоспособность
Найдите минутку, чтобы проверить функциональность вашей системы CentOS. Все ли у вас программное обеспечение запускается правильно и без ошибок? Все ли ваши сетевые функции работают правильно?
Протестируйте новое ядро ??так, чтобы все ошибки были вовремя обнаружены и исправлены. Или, если нет никаких исправлений, вы можете вернуться к старому ядру.
Шаг 8: Установите версию ядра по умолчанию
Убедившись, что новое ядро ??совместимо и работает правильно, вы захотите отредактировать загрузочную утилиту GRUB так, чтобы по умолчанию она загружала ваше новое ядро.
Перейдите в /etc/default/ и откройте файл grub в текстовом редакторе. Или введите в терминал следующее:
sudo vim /etc/default/grub
После открытия файла найдите строку с надписью GRUB_DEFAULT=X и измените ее на GRUB_DEFAULT=0. Эта строка проинструктирует загрузчик по умолчанию использовать первое ядро ??в списке, которое является последним.
Сохраните файл, а затем введите следующую команду в терминале, чтобы воссоздать конфигурацию ядра:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
Перезагрузитесь еще раз:
reboot
Убедитесь, что загрузчик настроен на загрузку последней версии ядра по умолчанию.
Итог
Готово! Мы обновили ядро CentOS до последней стабильной версии с помощью ELRepo.
Это продолжение статьи про пакетную коммутацию. Первая часть тут.
Схемы агрегации каналов берут несколько физических каналов и объединяют их в один виртуальный канал. В целях протоколов маршрутизации и алгоритмов предотвращения петель, таких как связующее дерево, виртуальный канал обрабатывается, как если бы он был одним физическим каналом.
Агрегирование каналов используется для увеличения пропускной способности между узлами сети без необходимости замены более медленных физических каналов на более быстрые. Например, два канала 10 Гбит/с можно объединить в один канал 20 Гбит/с, тем самым удвоив потенциальную полосу пропускания между двумя узлами, как показано на рисунке 6. Слово «потенциал» было выбрано тщательно, поскольку агрегированные каналы на практике не масштабируются линейно.
Проблема, с которой сталкивается агрегация каналов, заключается в определении, какие пакеты должны быть отправлены по какому элементу связи. Интуитивно это может показаться не проблемой. В конце концов, казалось бы, имеет смысл использовать группу каналов связи в циклическом режиме. Первоначальный фрейм будет отправлен по первому элементу связки, второй фрейм - по второму элементу и так далее, в конечном итоге возвращаясь к первому элементу связки. Таким образом, канал должен использоваться идеально равномерно, а пропускная способность - линейно.
В реальной жизни существует очень мало подобных реализаций, в которых агрегированные каналы используются на такой циклической основе, как эта, потому что они рискуют доставить неупорядоченные пакеты. Предположим, что первый кадр Ethernet отправляется первому звену нисходящего канала, а второй кадр - второму элементу нисходящего канала сразу после него. По какой-то причине второй кадр попадает на другой конец раньше первого кадра. Пакеты, содержащиеся в этих кадрах, будут доставлены принимающим узлам в неупорядоченном порядке - пакет два перед пакетом один. Это проблема, потому что теперь на хост возлагается вычислительная нагрузка по переупорядочению пакетов, чтобы можно было правильно собрать всю дейтаграмму.
Поэтому большинство поставщиков реализуют хеширование потоков, чтобы гарантировать, что весь поток трафика использует один и тот же элемент пакета. Таким образом, нет никакого риска того, что хост получит пакеты не по порядку, так как они будут отправляться последовательно через один и тот же элемент канала.
Хеширование потока работает путем выполнения математической операции над двумя или более статическими компонентами потока, такими как MAC-адреса источника и получателя, IP-адреса источника и получателя, протокол управления передачей (TCP) или протокол дейтаграмм пользователя (UDP). номера портов для вычисления элемента связи, который будет использовать поток. Поскольку характеристики потока статичны, алгоритм хеширования приводит к идентичным вычислениям для каждого кадра или пакета в потоке трафика, гарантируя, что один и тот же канал будет использоваться в течение всего срока службы потока.
Хотя хеширование потока решает проблему неупорядоченных пакетов, оно создает новую проблему. Не все потоки имеют одинаковый размер. Некоторые потоки используют большую полосу пропускания, например те, которые используются для передачи файлов, резервного копирования или хранения. Их иногда называют «слоновьими потоками» (elephant flows). Другие потоки довольно малы, например, те, которые используются для загрузки веб-страницы или связи с использованием передачи голоса по IP. Их иногда называют «мышиными потоками» (mouse flows). Поскольку потоки имеют разные размеры, некоторые элементы связи могут работать на полную мощность, а другие - недостаточно.
Это несоответствие в использовании возвращает нас к вопросу о линейном масштабировании. Если бы фреймы были сбалансированы по нагрузке через агрегированный набор каналов совершенно равномерно, то добавление новых каналов в набор равномерно увеличило бы емкость. Однако алгоритмы хэширования в сочетании с непредсказуемым объемом потоков трафика означают, что связанные каналы не будут загружаться равномерно.
Задача сетевого администратора - понять тип трафика, проходящего через агрегированный канал, и выбрать доступный алгоритм хеширования, который приведет к наиболее равномерному распределению нагрузки. Например, некоторые соображения по этому поводу:
Обмениваются ли многие хосты в одном широковещательном домене друг с другом через агрегированный канал? Хеширование против MAC-адресов, найденных в заголовке кадра Ethernet, является возможным решением, потому что MAC-адреса будут разными.
Обменивается ли небольшое количество хостов с одним сервером через агрегированный канал? В этом сценарии может не хватить разнообразия MAC-адресов или IP-адресов. Вместо этого хеширование по номерам портов TCP или UDP может привести к наибольшему разнообразию и последующему распределению трафика по агрегированным ссылкам.
Протокол управления агрегацией каналов (LACP)
При объединении каналов связи необходимо учитывать сетевые устройства на обоих концах канала связи и проявлять особую осторожность, чтобы обеспечить формирование пакета каналов связи при сохранении топологии без петель. Наиболее распространенным способом решения этой проблемы является использование отраслевого стандарта Link Aggregation Control Protocol (LACP), кодифицированного как стандарт 802.3 ad института инженеров электротехники и электроники (IEEE).
На каналах, обозначенных сетевым администратором, LACP объявляет о своем намерении сформировать агрегированный канал с другой стороной. Другая сторона, также выполняющая LACP, принимает это объявление, если объявленные параметры действительны, и формирует канал. Как только группа каналов сформирована, агрегированный канал переводится в состояние пересылки. Затем операторы сети могут запросить LACP для получения информации о состоянии агрегированного канала и о состоянии его членов.
LACP также знает, когда элемент связки выходит из строя, так как управляющие пакеты больше не проходят через сбойный канал. Эта возможность полезна, так как позволяет процессу LACP уведомлять сетевую операционную систему о необходимости пересчета хэшей потока. Без LACP сетевой операционной системе может потребоваться больше времени, чтобы узнать о сбойном канале, что приведет к хешированию трафика к элементу связи, который больше не является допустимым путем.
Существуют и другие протоколы управления агрегацией каналов. В некоторых случаях также возможно создавать пакеты каналов вручную без защиты управляющего протокола. Однако LACP доминирует в качестве стандарта, используемого сетевыми поставщиками, а также ведущими операционными системами и поставщиками гипервизоров для агрегации каналов.
Multichassis Link Aggregation
Multichassis Link Aggregation (MLAG) - это функция, предлагаемая некоторыми сетевыми поставщиками, позволяющая одному агрегированной связке каналов охватывать два или более сетевых коммутатора. Чтобы облегчить это, специальный протокол управления поставщика будет работать между коммутаторами-членами MLAG, заставляя несколько сетевых коммутаторов действовать так, как если бы они были одним коммутатором, в отношении LACP, протокола связующего дерева (STP) и любых других протоколов.
Обычным обоснованием для MLAG является физическая избыточность, когда сетевому инженеру требуется более низкий уровень (например, Ethernet) смежности между сетевыми устройствами (вместо маршрутизируемого соединения), а также требуется, чтобы связка каналов оставалась включенной, если удаленная сторона канала выходит из строя. Распространение связки каналов между двумя или более коммутаторами позволяет выполнить это требование. Рисунок 7 демонстрирует это.
В то время как многие сети используют некоторые разновидности MLAG в производстве, другие уклоняются от этой технологии, по крайней мере частично, потому что MLAG является собственностью. Нет такой вещи, как multivendor MLAG. Тенденции к лучшему проектированию сети в сторону от широко рассредоточенных коммутируемых доменов, сценарий, который выигрывает у MLAG. Вместо этого при проектировании сети наблюдается тенденция к ограниченным коммутируемым доменам, взаимосвязанным посредством маршрутизации, что устраняет необходимость в технологиях MLAG.
Маршрутизированные параллельные каналы
Маршрутизируемые плоскости управления, называемые протоколами маршрутизации, иногда вычисляют набор нескольких путей через сеть с равными затратами. В случае маршрутизации несколько каналов с одинаковой стоимостью могут даже не подключать одну пару устройств; Рисунок 8 демонстрирует это.
На рисунке 8 есть три пути:
[A, B, D] общей стоимостью 10
[A, D] общей стоимостью 10
[A, C, D] общей стоимостью 10
Поскольку эти три пути имеют одинаковую стоимость, все они могут быть установлены в локальной таблице переадресации в точках A и D. Маршрутизатор A, например, может пересылать трафик по любому из этих трех каналов в направлении D. Когда маршрутизатор имеет несколько вариантов. чтобы добраться до того же пункта назначения, как он решает, какой физический путь выбрать?
Как и в случае с ECMP нижнего уровня, ответ - хеширование. Маршрутизированное хеширование ECMP может выполняться в различных областях. Общие поля для хеширования включают IP-адреса источника или назначения и номера портов источника или назначения. В результате хеширования выбирается согласованный путь на протяжении потока L3. Только в случае сбоя канала потребуется перестроить поток и выбрать новый канал пересылки.
Механизмы обработки пакетов
Шаги, связанные с маршрутизацией одного пакета, могут показаться очень простыми—найдите пункт назначения в таблице, создайте (или извлеките) перезапись заголовка MAC, перепишите заголовок MAC, а затем поместите пакет в правильную очередь для исходящего интерфейса. Как бы просто это ни было, все равно требуется время, чтобы обработать один пакет. На рисунке 9 показаны три различных пути, по которым пакет может быть коммутироваться в сетевом устройстве.
Рисунок 9 иллюстрирует три различных пути коммутации через устройство; это не единственные возможные пути коммутации, но они являются наиболее распространенными. Первый путь обрабатывает пакеты через программное приложение, работающее на универсальном процессоре (GPP), и состоит из трех этапов:
Пакет копируется с физического носителя в основную память
Физический сигнальный процессор, чип PHY, посылает сигнал на GPP (вероятно, но не обязательно, главный процессор в сетевом устройстве), называемый прерыванием.
Прерывание заставляет процессор останавливать другие задачи (вот почему это называется прерыванием) и запускать небольшой фрагмент кода, который будет планировать запуск другого процесса, приложения коммутации, для выполнения позже.
Когда приложение коммутации запустится, оно выполнит соответствующий поиск и внесет соответствующие изменения в пакет.
После коммутации пакета он копируется из основной памяти исходящим процессором. Такое переключение пакета через процесс часто называется коммутацией процесса (по понятным причинам) или иногда медленным путем. Независимо от того, насколько быстрым является GPP, для достижения полной линейной скорости коммутации на высокоскоростных интерфейсах требуется большая настройка - до такой степени, что это практически невозможно. Второй путь коммутации, показанный на рисунке 9, был разработан для более быстрой обработки пакетов:
Пакет копируется с физического носителя в основную память
Микросхема PHY прерывает GPP; код обработчика прерывания, а не вызов другого процесса, фактически обрабатывает пакет.
После коммутации пакета, пакет копируется из основной памяти в процесс вывода, как описано ниже. По понятным причинам этот процесс часто называют interrupt context switching; многие процессоры могут поддерживать коммутацию пакетов достаточно быстро, чтобы передавать пакеты между интерфейсами с низкой и средней скоростью в этом режиме. Сам код коммутации, конечно же, должен быть сильно оптимизирован, потому что коммутация пакета заставляет процессор прекращать выполнение любых других задач (например, обработки обновления протокола маршрутизации). Первоначально это называлось - и до сих пор иногда называется fast switching path. Для действительно высокоскоростных приложений процесс коммутации пакетов должен быть выгружен с главного процессора или любого типа GPP на специализированный процессор, предназначенный для конкретной задачи обработки пакетов. Иногда эти процессоры называются сетевыми процессорами (Network Processing Units -NPU), подобно тому, как процессор, предназначенный для обработки только графики, называется графическим процессором (Graphics Processing Unit-GPU). Эти специализированные процессоры являются подмножеством более широкого класса процессоров, называемых специализированными интегральными схемами (Application-Specific Integrated Circuits -ASIC), и инженеры часто просто называют их ASIC. Переключение пакета через ASIC показано как шаги с 7 по 9 на рисунке 9:
Пакет копируется с физического носителя в память ASIC
Микросхема PHY прерывает работу ASIC; ASIC обрабатывает прерывание путем переключения пакета.
После коммутации пакета пакет копируется из памяти ASIC в процесс вывода, как описано ниже.
Многие специализированные ASIC для обработки пакетов имеют ряд интересных функций, в том числе:
Структуры внутренней памяти (регистры) настроены специально для обработки различных типов адресов, используемых в сетях.
Специализированные наборы команд, предназначенные для выполнения различных требований к обработке пакетов, таких как проверка внутренних заголовков, переносимых в пакете, и перезапись заголовка MAC.
Специализированные структуры памяти и наборы инструкций, предназначенные для хранения и поиска адресов назначения для ускорения обработки пакетов
Возможность повторного использования пакета через конвейер пакетов для выполнения операций, которые не могут поддерживаться за один проход, таких как глубокая проверка пакетов или специализированные задачи фильтрации.