По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Hyper-V - это платформа виртуализации в Windows Server. Hyper-V используется для создания виртуальных машин. Гипервизор также интегрирован в саму структуру облака Microsoft Azure. Эту роль можно включить и в некоторых выпусках Windows 10. Из этого следует, что можно переносить виртуальную машину из Windows 10 в Windows Server, в Azure и обратно без изменения формата виртуальной машины.
В этой статье рассмотрим тему использования оперативной памяти машины Hyper-V.
Динамическая память
Имеется два варианта выделения памяти виртуальным машинам. Может назначаться статический объем памяти или установить параметр динамической памяти. Если назначается статическая величина, то этот объем памяти остается неизменным, независимо в каком состоянии находится виртуальная машина.
При установке динамической памяти в Параметрах можно настроить следующие значения через Windows Admin Center или Консоль Hyper-V:
Startup Memory - это тот объем памяти, который нужен для старта гостевой машины. Он может быть таким же, как минимальный объем памяти, или может быть таким же, как максимальный объем выделенной памяти. После запуска виртуальная машина вместо этого будет использовать то значение, которое указано, как минимальный объем памяти.
Минимальный объем (Minimum Memory. - т.е. меньше указанного значения сервер виртуализации не выделит объем памяти при использовании динамического распределения. Если нескольким виртуальным машинам требуется больше памяти, Hyper-V может уменьшить объем другой виртуальной машины до тех пор, пока не будет достигнуто значение минимального ее объема. Вы можете уменьшить параметр минимального объема памяти во время работы виртуальной машины, но не можете увеличить его, когда виртуальная машина работает.
Максимальный объем памяти (Maximum Memory) - это максимальное значение объема памяти, которое будет выделять хостом виртуализации при включении динамической памяти для виртуальной машины. Вы можете увеличить максимальный объем памяти во время работы виртуальной машины, но не можете уменьшить его, пока виртуальная машина работает.
Memory Buffer - процент памяти, который хост должен выделить виртуальной машине в качестве резерва.
Memory Weight - позволяет настроить способ распределения памяти для разных гостевых систем по отношению друг к другу, запускающихся на том же узле виртуализации.
Как правило, когда вы настраиваете динамическую память, объем используемой памяти будет колебаться между значениями Минимум и Максимум. Следует проводить мониторинг использования памяти ВМ и настраивать эти значения так, чтобы они точно отражали фактические потребности виртуальной машины. в Случае, когда будет выделено минимальное значение памяти ниже того, что фактически необходимо для запуска виртуальной машины, эта нехватка может привести к тому, что узел виртуализации уменьшит объем памяти, выделенной для этого минимального значения памяти, что приведет к остановке работы виртуальной машины.
Smart paging - это специальная технология в Hyper-V, которая работает в определенных условиях при перезагрузке виртуальной машины. Smart paging использует файл на диске для имитации ОЗУ удовлетворения требований к загрузочной памяти, когда значение параметра Startup Memory (память, выделяемая на момент запуска) превышает значение Minimum Memory. Например, вы можете выставить стартовую память на 2048 МБ и минимальную память на 512 МБ для конкретной виртуальной машины. В сценарии, когда на узле виртуализации было доступно 1024 МБ свободной памяти, интеллектуальная подкачка позволит виртуальной машине получить доступ к требуемым 2048 МБ памяти.
Интеллектуальная подкачка активна только в том случае, если одновременно выполняются следующие три условия:
Виртуальная машина перезагружается.
На хосте виртуализации не хватает памяти для соответствия параметру Startup Memory.
Память не может быть освобождена от других виртуальных машин, работающих на том же хосте.
Smart paging не позволит виртуальной машине выполнять "холодный запуск", если необходимый объем памяти для запуска недоступен, но доступен минимальный объем памяти. Функционал используется только тогда, когда виртуальная машина, которая уже работала, перезагружается и выполняются два вышеуказанных условия.
Расположение файла для каждой виртуальной машины можно изменять. По умолчанию они создаются в папке C:ProgramDataMicrosoftWindowsHyper-V. Файл интеллектуальной подкачки создается только при необходимости и удаляется в течение 10 минут после перезапуска виртуальной машины. Расположение файла можно изменить, используя графический интерфейс консоли Hyper-V или командлетом PowerShell, например:
Set-VM "Windows 10" -SmartPagingFilePath D:SmartPaging
Каждое семейство операционных систем производит загрузку по-своему. Это связанно с различной архитектурой ядра операционной системы, разными инструкциями по работе с подключенными устройствами. В данной статье попробую разобрать загрузку популярной операционной системы на ядре Linux Ubuntu.
Схематично процесс загрузки можно отобразить следующим образом.
Загружаемся
Итак, Нажимаем кнопку включения компьютера, и центральный процессор переходит на адрес BIOS. BIOS или UEFI, в более современных компьютерах, проводит систему проверок и выбирает носитель информации с которого будет производится загрузка операционной системы. На носителе находится MBR (Master Boot Record) или GPT (Guid Partition table) на новых компьютерах в которых находится загрузчик. А дальше уже в зависимости от настройки. Загрузчик может самостоятельно загружать операционную систему, а может передавать управление следующему загрузчику. Например, если Windows и Linux установлены на одном компьютере и находятся на разных разделах жесткого диска.
В любом случае, если идет речь о Linux у нас есть первая стадия с небольшой частью кода, которая загружает у нас загрузчик. Загрузчик знает где лежит ядро операционной системы, загружает ядро, загружает initial run disk, там находятся необходимые файлы и модули для загрузки ядра. Далее уже ядро берет процесс управления на себя. Происходит инициализация устройств, конфигурирование процессов памяти и так далее. После всех этих процессов ядро запускает процесс init.
Вернемся к вопросу загрузчиков, для каждой операционной системы разработан свой загрузчик, а иногда и несколько. NTLDR - Загрузчик операционной системы Windows, LILO - один из стандартных загрузчиков для Linux и BSD системы. GRUB - загрузчик операционной системы от проекта GNU. Нас интересуют последние два. Данные загрузчики работают в два этапа. На первом этапе у них крошечный код на MBR или GPT, который запускает исполнение кода второго этапа.
Перейдем непосредственно к самой загрузке.
Данное меню мы можем получить при загрузке если зажать клавишу Shift. Как видно на картинке в данном примере загрузчик GRUB версии 2.04. У нас есть несколько вариантов. Загрузка Ubuntu по умолчанию и вариант загрузки с расширенными опциями. В нашем случае расширенные опции не дают многого, а всего лишь позволяют начать загрузку в режиме восстановления recovery mode. Данная опция не является целью стати, и мы ее опустим. Вернемся к первому пункту загрузки. Выбираем, нажимаем "e" получаем следующую картину загрузки.
На данной картинке можно увидеть, что корневой раздел монтируется по uuid, он будет корневым root и непосредственно сам id. ID раздела можно посмотреть после загрузки операционной системы командой blkid. Можно часть параметров отредактировать или большинство. Более подробно можно поискать в интернете. По нажатию F10 осуществляется продолжение загрузки операционной системы.
После загрузки операционной системы, мы можем с помощью команды dmesg посмотреть, сообщения ядра, все что происходило с ядром. Нужно различать сообщения ядра и лог ядра. Который можно посмотреть cat /var/log/dmesg. Данный файл содержи информацию только о загрузке операционной системы. В данном файле содержится информация с самого начала загрузки операционной системы и до конца. Если событие происходит позднее, то в данном файле этой информации вы не найдете.
Система инициализации ОС
Есть такое понятие Init - это первый или родительский процесс, который запускает все последующие процессы. Это может быть проверка и монтирование файловых систем запуск служб и.т.д. Существует 3 варианта работы этого родительского процесса.
Init в стиле SysV - родительский процесс инициализации системы на одном из заданных уровней запуска (runlevel); Т.е. есть несколько уровней загрузки (runlevel) обычно их 7 штук. Один из них - это обычный многопользовательский режим. Другие это выключение компьютера, перезагрузка, режим восстановления и т.д.
Init в стиле systemd - родительский процесс инициализации системы в ускоренном режиме, за счёт параллельного запуска задач; Ускоренный режим достигается за счет использования процессора в частности Intel, который позволяет запускать процессы инициализации параллельно. К этому режиму есть еще куча софта библиотек, которые расширяют функционал.
Init в стиле Upstart - родительский процесс инициализации системы на основе отслеживания событий; Данный режим используется на Ubuntu уже давным - давно, тут не только запускаются скрипты инициализации, но и запускаются скрипты отслеживания событий и реагирования на них. Т.е. это более гибкий процесс инициализации, например, если какая-то служба не запустилась или упала в процессе загрузки то, upstart умеет это отследить и запустить это повторно
В операционной систему Ubuntu можно посмотреть дерево процессов использую команду pstree. В результате ее вывода мы можем увидеть, что родительским процессом являлся процесс systemd. Который запускал уже свои, какие-то дочерние процессы. Перейдем в корневую директорию boot.
Здесь мы можем увидеть директорию загрузчика grub. Ядра линуксовые vmlinuz (ссылка на ядро) и до обновления старое ядро vmlinux.old (ссылка на старое ядро). Соответственно пара initrd* - файлы диска, эти файлы содержат диск, который грузится в оперативную память, данный диск содержит файлы необходимые самому ядру Linux для нормальной загрузки.
Перейдя в директорию grub, мы можем найти конфигурационный файл grub.cfg и несколько вспомогательных, но не менее важных фалов. Соответственно мы можем внести изменения в данный файл на постоянной основе и соответственно данный код будет выполнятся при каждой загрузке операционной системы.
Public Key Infrastructure (PKI) - это набор различных технологий, которые используются для обеспечения аутентификации источника, целостности данных и конфиденциальности для пользователя в сети. PKI использует преимущества асимметричного шифрования и использует пары открытого и закрытого ключей для шифрования данных.
В PKI открытый ключ обычно связан с цифровой подписью, чтобы добавить доверие и проверить сведения о владельце сертификата. Ниже приведен ключевой жизненный цикл в PKI:
Генерация ключа: Этот процесс определяет шифр и размер ключа.
Генерация сертификата: Этот процесс создает цифровой сертификат и назначает его человеку или устройству.
Распространение: Процесс распространения отвечает за безопасное распространение ключа пользователю или устройству.
Хранение: Этот процесс отвечает за безопасное хранение ключа, чтобы предотвратить любой несанкционированный доступ к нему.
Отзыв: Сертификат или ключ могут быть отозваны, если они скомпрометированы субъектом угрозы.
Срок действия: Каждый сертификат имеет срок службы.
Каждый день мы посещаем различные веб-сайты, такие как социальные сети, стрим, новости, спорт, блоги и другие платформы. Однако задумывались ли вы когда-нибудь о проверке подлинности веб-сайтов, которые вы посещаете? Вы, наверное, думаете, что всему, что находится в Интернете, нельзя доверять. Хотя это отчасти правда, мы можем доверять только ограниченному числу веб-сайтов, например, доверять веб-сайту вашего банка. Главный вопрос заключается в том, как мы можем проверить подлинность веб-сайтов, которые мы посещаем? Именно здесь как PKI, так и цифровые сертификаты помогают установить доверие между хостом в Интернете и нашим компьютером.
Центр сертификации
PKI играет жизненно важную роль в Интернете, поскольку многим пользователям и устройствам требуется метод установления доверия в самой ненадежной сети в мире – Интернете. Понимание компонентов, которые помогают PKI обеспечить доверие, необходимую как пользователям, так и устройствам, имеет важное значение для любого специалиста по кибербезопасности.
Вы можете рассматривать PKI как набор процедур, правил, аппаратного и программного обеспечения, а также людей, которые работают вместе для управления цифровыми сертификатами. Цифровой сертификат-это официальная форма идентификации объекта, которая проверяется доверенной стороной. Эти цифровые сертификаты выдаются доверенной стороной в сети или Интернете. Они известны как Центр сертификации (Certificate Authority - CA).
В каждой стране существует государственное учреждение, которое обычно отвечает за проверку личности своих граждан и выдачу удостоверений личности, такой как паспорт.
Этот паспорт будет содержать важную информацию о владельце и сроке действия, например, дату окончания срока действия. В сети и в Интернете центр сертификации выполняет похожую роль и функции. В Интернете есть множество поставщиков, которые являются доверенными центрами сертификации, которые позволяют вам приобретать цифровой сертификат для личного использования. Примеры доверенных центров сертификации включают GoDaddy, DigiCert, Let's Encrypt, Comodo, Cloudflare и многие другие.
Важное примечание! Цифровой сертификат создается при объединении ключа и цифровой подписи. Сертификат будет содержать сведения о владельце сертификата, например, об организации.
ЦС выдаст объекту цифровой сертификат только после того, как его личность будет проверена. После того, как ЦС создает цифровой сертификат, он сохраняется в базе данных сертификатов, которая используется для безопасного хранения всех утвержденных ЦС цифровых сертификатов.
Важное примечание! По истечении срока действия цифрового сертификата он возвращается в ЦС, который затем помещается в список отзыва сертификатов (Certificate Revocation List - CRL), который поддерживается ЦС.
Цифровой сертификат форматируется с использованием стандарта X.509, который содержит следующие сведения:
Номер версии
Серийный номер
Идентификатор алгоритма подписи
Название эмитента
Срок годности
Не раньше, чем
Не после
Имя субъекта
Информация об открытом ключе субъекта
Алгоритм открытого ключа
Открытый ключ субъекта
Уникальный идентификатор эмитента (необязательно)
Уникальный идентификатор субъекта (необязательно)
Расширения (необязательно)
Алгоритм подписи сертификата
Подпись сертификата
Регистрирующий орган (RA)
Следующий рисунок - это цифровой сертификат, который используется для проверки веб-сайта Cisco:
Как показано на предыдущем рисунке, видно, что CA - это HydrantID SSH ICA G2, который выдает сертификат на www.cisco.com на срок действия с 20 сентября 2019 года по 20 сентября 2021 года.
Как показано на следующем рисунке, цифровой сертификат содержит дополнительную информацию, которая хранится с использованием стандарта X.509:
Далее давайте рассмотрим, как создается цифровая подпись и ее роль в PKI.
Цифровая подпись
При совершении деловых операций на документах требуется подпись, чтобы гарантировать, что сделка санкционирована соответствующим лицом. Такая же концепция требуется в сети, так что цифровая подпись отправляется вместе с сообщением на конечный хост. Затем узел назначения может использовать цифровую подпись для проверки подлинности сообщения.
При использовании PKI используются следующие алгоритмы для создания и проверки цифровых подписей:
DSA
RSA
Elliptic Curve Digital Signature Algorithm (ECDSA)
Чтобы создать цифровую подпись, между Алисой (отправителем) и Сергеем Алексеевичем (получателем) происходит следующий процесс:
1) Алиса будет использовать алгоритм хеширования для создания хэша (дайджеста) сообщения:
2) Затем Алиса будет использовать свой закрытый ключ для шифрования хэша (дайджеста) сообщения:
Цифровая подпись используется в качестве доказательства того, что Алиса подписала сообщение.
Чтобы лучше понять, как используются цифровые подписи в реальной жизни, давайте представим, что в сети есть два пользователя. Алиса хочет отправить Сергею Алексеевичу сообщение. Алиса может использовать цифровую подпись с сообщением, чтобы заверить Сергея Алексеевича в том, что сообщение исходило именно от нее. Это шаги, которые Алиса будет использовать для обеспечения подлинности, целостности и неотрицания:
Алиса создаст пару открытых и закрытых ключей для шифрования данных.
Алиса даст Сергею Алексеевичу только открытый ключ. Таким образом, закрытый ключ хранится у Алисы.
Алиса создаст сообщение для Сергея Алексеевича и создаст хэш (дайджест) сообщения.
Затем Алиса будет использовать закрытый ключ для шифрования хэша (дайджеста) сообщения для создания цифровой подписи.
Алиса отправит сообщение и цифровую подпись Сергею Алексеевичу.
Сергей Алексеевич будет использовать открытый ключ Алисы для расшифровки цифровой подписи, чтобы получить хэш сообщения.
Сергей Алексеевич также сгенерирует хэш сообщения и сравнит его с хэшем, полученным из цифровой подписи Алисы. Как только два значения хэша (дайджеста) совпадают, это просто означает, что сообщение подписано и отправлено Алисой.
Цифровые подписи используются не только для проверки подлинности сообщений. Они также используются в следующих случаях:
Цифровые подписи для цифровых сертификатов: это позволяет отправителю вставить цифровую подпись в цифровой сертификат.
Цифровые подписи для подписи кода: это позволяет разработчику приложения вставить свою цифровую подпись в исходник приложения, чтобы помочь пользователям проверить подлинность программного обеспечения или приложения.
На следующем рисунке показан пример приложения, содержащего цифровой сертификат:
На следующем рисунке показана дополнительная проверка цифровой подписи подписавшего:
Система доверия PKI
Ранее мы узнали, что организация может получить цифровой сертификат от доверенного центра сертификации в Интернете. Однако во многих крупных организациях вы обычно найдете корневой ЦС и множество промежуточных ЦС. Корневой ЦС отвечает за создание первичного цифрового сертификата, который затем делегируется каждому подчиненному ЦС или промежуточному ЦС. Промежуточный ЦС будет использовать цифровой сертификат корневого сервера для создания новых цифровых сертификатов для конечных устройств, таких как внутренние серверы.
На следующем рисунке показана иерархия корневого и промежуточного ЦС:
Использование этого типа иерархической структуры снимает нагрузку с корневого центра сертификации по управлению всеми цифровыми сертификатами в организации. Некоторые из этих обязанностей делегированы промежуточным серверам ЦС в сети. Представьте, что в вашем головном офисе вы развернули корневой ЦС, а в каждом удаленном филиале развернули промежуточные ЦС. Следовательно, каждый промежуточный ЦС отвечает за управление сертификатами своего собственного домена или филиала. Это также снижает риски взлома корневого ЦС злоумышленником, так что в случае взлома промежуточного ЦС корневой ЦС может быть отключен от сети, не затрагивая другие конечные устройства или промежуточные ЦС.
В небольших сетях можно развернуть один корневой ЦС для предоставления цифровых сертификатов каждому конечному устройству, как показано на следующем рисунке:
Как показано на предыдущем рисунке, одним ЦС легко управлять. Однако по мере роста сети наличие единственного центра сертификации в сети не позволит легко масштабироваться, поэтому необходимо использовать иерархическую структуру с корневым центром сертификации и промежуточными (подчиненными) центрами сертификации.