По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Каждое семейство операционных систем производит загрузку по-своему. Это связанно с различной архитектурой ядра операционной системы, разными инструкциями по работе с подключенными устройствами. В данной статье попробую разобрать загрузку популярной операционной системы на ядре 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 и несколько вспомогательных, но не менее важных фалов. Соответственно мы можем внести изменения в данный файл на постоянной основе и соответственно данный код будет выполнятся при каждой загрузке операционной системы.
Управление компьютерными сетями - дело непростое. В последние годы всеобщая компьютеризация вызвала огромный скачок в расширении компьютерных сетей. Это добавило работы системному администратору. Ведь если ранее были распространены небольшие сети, то добавление и настройка новых устройств, либо обновление ПО на уже находящихся требовали ручной настройки операционной системы, а то и установки на каждом из них. Это требовало времени и нервов администратора. Сейчас же, когда сети насчитывают сотни, а то и тысячи машин, ручная настройка требует либо участия многих специалистов (а это порождает проблему плохой совместимости согласно человеческому фактору, каждый админ мыслит по-своему), либо очень долгого времени, если этим будет заниматься один специалист.
Такая проблема, с учетом технического прогресса, породила решение об автоматизации. На сегодняшний день существует специализированное программное обеспечение, которое позволяет присоединиться к удаленным машинам, и в автоматическом режиме произвести настройки операционной системы для корректной работы сети. Однако, как быть, если на нужных компьютерах в рамках одной сети установлены разные операционные системы? Ведь сейчас компьютеры под Linux, FreeBSD и Windows, объединенные в одну сеть - далеко не редкость. Поэтому одним из требований к управляющей программе стала кроссплатформенность. В этом случае одним из самых эффективных решений является такая программа, как Puppet.
Puppet это один из самых нужных инструментов сетевого администратора. Это приложение создано специально для управления конфигурацией операционных систем внутри одной сети. Оно имеет клиент-серверную архитектуру, то есть администратор, находящийся за сервером, может отправлять данные конфигурации на периферийные машины, на которых установлена клиентская часть. На этих рабочих станциях система в автоматическом режиме сконфигурирует себя в соответствии с присланными с сервера настройками.
Важным моментом является кроссплатформенность. Простота настройки и управления самыми распространенными операционными системами делает Puppet одним из самых актуальных решений по управлению компьютерными сетями на сегодняшний день.
Как же работает Puppet? Разберем подробнее. Для начала, на сервер нужно установить серверную часть программы. Поскольку приложение написано на Ruby, на серверной рабочей станции обязательно должна быть установлена нужная программная среда.
Серверная часть программы создана для хранения манифестов так в программной терминологии Puppet называются файлы с настройками конфигурации. В процессе работы сервер принимает обращения с клиентских машин и автоматически отсылает им обновленные файлы конфигурирования ОС для работы в сети.
На клиентских компьютерах также должно быть установлено программное обеспечение Puppet, уже в виде клиентской части. Как правило, данные установочные пакеты включаются в саму операционную систему, что позволяет быстро развертывать компьютерную сеть, однако, в случае их отсутствия, придется скачивать необходимую сборку с сайта разработчика.
Дополнительное удобство данного решения в том, что один администратор с помощью сервера может осуществить настройку и управление сотен и тысяч машин, объединенных в сеть. Если возникнут какие-то проблемы, то отклик с мест позволит админу быстро поправить код и устранить их. Хотя в данном случае возрастают требования к внимательности админа - одна неверно написанная строка кода конфигурации может привести к неполадкам по всей сети. Хотя, если разобраться, в данном случае можно запустить работающий манифест предыдущей сборки и восстановить все достаточно оперативно.
Напомним немного про OSI
Современный мир немыслим без средств связи. Десятки миллионов устройств по всему миру связываются посредством компьютерных сетей. И каждая компьютерная сеть организована по определенным стандартам. Любые устройства взаимодействуют по общепринятой модели OSI, или Базовой Эталонной Модели Взаимодействия Открытых Систем. Данная модель определяет взаимодействие различных сетевых устройств на семи уровнях – Media (к ним относятся физический, канальный и сетевой) и Host – (транспортный, сеансовый, представления и прикладной). В данной статье мы рассмотрим два самых распространенных сетевых протокола транспортного уровня – TCP и UDP, примеры их применения, а также сравним их характеристики.
Видео: TCP и UDP | что это такое и в чем разница?
В чем же разница TCP и UDP?
Вообще, протоколы транспортного уровня широко применяются в современных сетях. Именно они позволяют гарантировать доставку сообщения до адресата, а также сохраняют правильную последовательность передачи данных. При этом протоколы имеют ряд различий, что позволяет использовать их профильно, для решения своих задач каждый.
Протокол TCP (Transmission Control Protocol) – это сетевой протокол, который «заточен» под соединение. Иными словами, прежде, чем начать обмен данными, данному протоколу требуется установить соединение между двумя хостами. Данный протокол имеет высокую надежность, поскольку позволяет не терять данные при передаче, запрашивает подтверждения о получении от принимающей стороны и в случае необходимости отправляет данные повторно. При этом отправляемые пакеты данных сохраняют порядок отправки, то есть можно сказать, что передача данных упорядочена. Минусом данного протокола является относительно низкая скорость передачи данных, за счет того что выполнение надежной и упорядоченной передачи занимает больше времени, чем в альтернативном протоколе UDP.
Протокол UDP (User Datagram Protocol), в свою очередь, более прост. Для передачи данных ему не обязательно устанавливать соединение между отправителем и получателем. Информация передается без предварительной проверки готовности принимающей стороны. Это делает протокол менее надежным – при передаче некоторые фрагменты данных могут теряться. Кроме того, упорядоченность данных не соблюдается – возможен непоследовательный прием данных получателем. Зато скорость передачи данных по данному транспортному протоколу будет более высокой.
Заключение и наглядное сравнение
Приведем несколько основных пунктов:
Надежность: в этом случае предпочтительнее будет протокол TCP, за счет подтверждения получения данных, повторной отправки в случае необходимости, а также использованию такого инструмента как тайм-аут. Протокол UDP такого инструментария не имеет, а потому при получении отправленные данные могут приходить не полностью;
Упорядоченность: опять будет предпочтительнее TCP, поскольку этот протокол гарантирует передачу пакетов данных именно в том порядке, в котором они были отправлены. В случае с UDP такой порядок не соблюдается;
Скорость: здесь уже лидировать будет UDP, так как более тяжеловесному TCP-протоколу будет требоваться больше времени для установки соединения, подтверждения получения, повторной отправки данных и т.д. ;
Метод передачи данных: в случае с TCP данные передаются потоково, границы фрагментов данных не имеют обозначения. В случае с UDP данные передаются в виде датаграмм – проверка пакетов на целостность осуществляется принимающей стороной только в случае получения сообщения. Также пакеты данных имеют определенные обозначения границ;
Сравнивая оба протокола, очевидно, что протокол TCP – это, можно сказать, «снайпер». Прицелился, выстрелил, зафиксировал попадание, ищет следующую цель. UDP – это, скорее, «пулеметчик» - выставил ствол в направлении врага и начал долбить очередями, не слишком заботясь о точности. Как в войсках важны обе эти воинские специальности, так и в интернете важны оба этих протокола. TCP применяется там, где требуется точная и подтверждаемая передача данных – например, отправка фотографий, или переписка между пользователями. UDP, в свою очередь, нужен для общения в голосовом формате, или при передаче потокового видео, например, с веб-камер или IP-камер.