По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В сегодняшней статье, расскажем как установить последнюю версию операционной системы CentOS 7, в среде виртуализации Hyper-V, по средствам опции сетевой установки или Network Installation.
Примечание: В процессе сетевой установки, все файлы и пэкэджи, которые необходимы для операционной системы, будут скачиваться непосредственно из Интернета с зеркала, которое Вы укажете. Поэтому прежде чем воспользоваться данным методом, рекомендуем убедиться, что у Вас хорошее Интернет соединение.
Пошаговое видео
Подготовка
Первое, что необходимо сделать, это скачать специальный загрузочный образ CentOS 7. В зависимости от архитектуры Вашей ОС, он доступен по ссылкам ниже. Например, образ для 64-разрядной системы можно скачать по это ссылке
Выбираете любое понравившееся зеркало и открывайте список доступных файлов. Нам необходим образ CentOS 7 Netinstall ISO.
Образ для сетевой установки, Netinstall, имеет размер всего лишь приблизительно 386 Мегабайт, тогда как полный образ CentOS 7 весит порядка 4 Гигабайт.
Это связано с тем, что в образе Netinstall находятся только метаданные, позволяющие выбрать, с каким именно функционалом будет установлена операционная система.
Установка
Итак, давайте приступим к установке. Запускаем Hyper-V Manager и первое, что необходимо сделать это создать виртуальный свич. Для этого нажимаем Virtual Switch Manager → New virtual network switch → External и нажать Create Virtual Switch.
И выбираем сетевую карту, которую нужно использовать для подключения виртуальных машин к сети и кликаем OK.
Теперь приступим непосредственно к созданию виртуальной машины. Для этого нажимаем New → Virtual machine, задаём машине имя и кликаем Next.
Поколение (Generation) виртуальной машины оставляем первое - Generation 1
Далее нужно выделить объём оперативной памяти, которая будет использоваться данной виртуальной машиной. По умолчанию - это 1 гигабайт (1024 MB) и для наших целей этого вполне достаточно.
Далее необходимо выбрать виртуальный свич (Virtual Switch), который будет использоваться для подключения к сети нашей виртуальной машины. В нашем случае – это VSWITCH_1.
Далее создаём виртуальный жёсткий диск для установки на него операционной системы CentOS 7. Выберем размер 15 Гигабайт и укажем путь на нашем локальном компьютере, где будет храниться образ данного виртуального жесткого диска. Рекомендуем выбирать место на диске D://
Далее необходимо указать способ загрузки образа нашей виртуальной машиной. Выбираем Install an operating system from bootable CD/DVD ROM → Image file и указываем путь к нашему недавно скачанному образу CentOS7 Netinstall.
Итак, виртуальная машина создана. Подключаемся к ней и выбираем Install CentOS Linux 7
Через некоторое время, перед нами открывается помощник установки. Опции установщика разделяются на три части: Localization, Software и System.
В части Localization, настраивается системное время, раскладки клавиатуры и поддерживаемые языки.
В части Software, мы указываем источник, откуда будут загружаться файлы для нашей операционной системы и необходимый функционал.
И в части System настраиваем куда будет устанавливаться наша операционная система, политики безопасности и сетевые опции.
Поскольку в процессе сетевой установки все файлы для CentOS 7 будут скачиваться из Интернета, необходимо подключить наш виртуальный сервер с операционной системой к сети. Для этого выбираем Network and Hostname и “включаем” сеть, передвинув ползунок в положение ON. Тем самым мы задействовали наш виртуальный свич.
Теперь можно указывать путь к репозиторию, откуда мы хотим загружать файлы. Выбираем Installation Source и в появившемся окне указываем путь. Я укажу репозиторий CentOS - http://mirror.centos.org/centos/7/os/x86_64/
После этого, начнётся скачивание метаданных и спустя какое то время, источник будет выбран и мы увидим адрес репозитория, который указали.
В разделе Software Selection можно выбрать функционал, для целей которого будет использоваться сервер.
Теперь всё готово к установке, нажимаем Begin Installation.
Пока идёт установка, можно настроить пароль для root пользователя системы.
Процесс установки может занимать от 15 до 30 минут, это напрямую зависит от характеристик Вашего компьютера. Как только установка будет закончена, нам предложат перезапуститься. Нажимаем кнопку Reboot.
После перезагрузки, наш сервер на базе операционной системы CentOS 7 будет готов к использованию. Для доступа на сервер, необходимо ввести реквизиты доступа, которые мы вводили при создании root пользователя.
OSPF (Open Shortest Path First) – дословно переводится как «Сперва открытый короткий путь» - надежный протокол внутренней маршрутизации с учетом состояния каналов (Interior gateway protocol, IGP). Как правило, данный протокол маршрутизации начинает использоваться тогда, когда протокола RIP уже не хватает по причине усложнения сети и необходимости в её легком масштабировании.
OSPF наиболее широко используемый протокол внутренней маршрутизации. Когда идёт речь о внутренней маршрутизации, то это означает, что связь между маршрутизаторами устанавливается в одном домене маршрутизации, или в одной автономной системе. Представьте компанию среднего масштаба с несколькими зданиями и различными департаментами, каждое из которых связано с другим с помощью канала связи, которые дублируются с целью увеличения надежности. Все здания являются частью одной автономной системы. Однако при использовании OSPF, появляется понятие «площадка», «зона» (Area), которое позволяет сильнее сегментировать сеть, к примеру, разделение по «зонам» для каждого отдельного департамента.
Видео: протокол OSPF (Open Shortest Path First) за 8 минут
Для понимания необходимости данных «зон» при проектировании сети, необходимо понять, как OSPF работает. Есть несколько понятий, связанных с этим протоколом, которые не встречаются в других протоколах и являются уникальными:
Router ID: Уникальный 32-х битный номер, назначенный каждому маршрутизатору. Как правило, это сетевой адрес с интерфейса маршрутизатора, обладающий самым большим значением. Часто для этих целей используется loopback интерфейс маршрутизатора.
Маршрутизаторы-соседи: Два маршрутизатора с каналом связи между ними, могут посылать друг другу сообщения.
Соседство: Двухсторонние отношения между маршрутизаторами-соседями. Соседи не обязательно формируют между собой соседство.
LSA: Link State Advertisement – сообщение о состоянии канала между маршрутизаторами.
Hello сообщения: С помощью этих сообщений маршрутизаторы определяют соседей и формируют LSA
Area (Зона): Некая иерархия, набор маршрутизаторов, которые обмениваются LSA с остальными в одной и той же зоне. Зоны ограничивают LSA и стимулируют агрегацию роутеров.
OSPF – протокол маршрутизации с проверкой состояния каналов. Представьте себе карту сети – для того, чтобы ее сформировать, OSPF совершает следующие действия:
Сперва, когда протокол только запустился на маршрутизаторе, он начинает посылать hello-пакеты для нахождения соседей и выбора DR (designated router, назначенный маршрутизатор). Эти пакеты включают в себя информацию о соседях и состоянии каналов. К примеру, OSPF может определить соединение типа «точка-точка», и после этого в протоколе данное соединение «поднимается», т.е. становится активным. Если же это распределенное соединение, маршрутизатор дожидается выбора DR перед тем как пометить канал активным.
Существует возможность изменить Priority ID для, что позволит быть уверенным в том, что DR-ом станет самый мощный и производительный маршрутизатор. В противном случае, победит маршрутизатор с самым большим IP-адресом. Ключевая идея DR и BDR (Backup DR), заключается в том, что они являются единственными устройствами, генерирующими LSA и они обязаны обмениваться базами данных состояния каналов с другими маршрутизаторами в подсети. Таким образом, все не-DR маршрутизаторы формируют соседство с DR. Весь смысл подобного дизайна в поддержании масштабируемости сети. Очевидно, что единственный способ убедиться в том, что все маршрутизаторы оперируют одной и той же информацией о состоянии сети – синхронизировать БД между ними. В противном случае, если бы в сети было 35 маршрутизаторов, и требовалось бы добавить еще одно устройство, появилась бы необходимость в установлении 35 процессов соседства. Когда база централизована (т.е существует центральный, выбранный маршрутизатор - DR) данный процесс упрощается на несколько порядков.
Обмен базами данных – крайне важная часть процесса по установлению соседства, после того как маршрутизаторы обменялись hello-пакетами. При отсутствии синхронизированных баз данных могут появиться ошибки, такие как петли маршрутизации и т.д. Третья часть установления соседства – обмен LSA. Это понятие будет разобрано в следующей статье, главное, что необходимо знать – нулевая зона (Area 0) особенная, и при наличии нескольких зон, все они должны быть соединены с Area 0. Так же это называется магистральной зоной.
Типы маршрутизаторов OSPF
Разберем различные типы маршрутизаторов при использовании протокола OSPF:
ABR
Area Border Router – маршрутизатор внутри нулевой зоны, через который идет связь с остальными зонами
DR, BDR
Designated Router, Backup Designated Router – этот тип маршрутизаторов обсуждался выше, это основной и резервирующий маршрутизаторы, которые ответственны за базу данных маршрутизаторов в сети. Они получают и посылают обновления через Multicast остальным маршрутизаторам в сети.
ASBR
Autonomous System Boundary Router – этот тип маршрутизаторов соединяет одну или несколько автономных систем для осуществления возможного обмена маршрутами между ними.
Подведем итоги
OSPF является быстро сходящимся протоколом внутренней маршрутизации с контролем состояния каналов
Процесс соседства формируется между соседними маршрутизаторами через DR и BDR, используя LSA
Зоны в данном протоколе маршрутизации используются для ограничения LSA и суммирования маршрутов. Все зоны подключаются к магистральной зоне.
Производительность приложений может оказаться решающим показателем для многих предприятий. Если уж на то пошло, то стоимость размещения серверного оборудования напрямую влияет на ваш чистый доход. Именно поэтому если вы будете использовать инструменты профилирования производительности для отладки запускаемого кода, вы сможете в итоге сэкономить ваши деньги.
На что стоит обратить внимание
«Узкое место» - это любая медленно работающая часть вашего приложения, которая замедляет остальную часть, которая работает быстрее, прямо как крышка на бутылке с водой или узкая дорога, которая мешает движению транспорта. Абсолютно любой код, который вы пишете, с большей долей вероятности имеет узкие места, и неважно, маленькие они или большие, вы в любом случае можете использовать инструменты профилирования производительности, чтобы их найти.
Все программы разные, но, как правило, страдают от одних и тех же проблем:
Функции вызываются слишком часто (кэширование или планирование могут уменьшить количество вызовов).
Код блокировки ввода-вывода, обычно сюда относится синхронный доступ к диску, но иногда и чрезмерное использования памяти.
Большое количество циклов с затратными методами.
Длительное время запуска, особенно в JIT-компилируемых языках.
Нецелесообразное выделение памяти, особенно при работе программы сборки мусора.
Области, которые выиграют от распараллеливания или асинхронного программирования.
При проверке вашего кода с помощью профилировщика вы сможете выявить любые из них. Даже если у вашего приложения нет какого-то серьезного заметного узкого места, в любом случае даже минимальный процент улучшения поспособствует тому, что ваше приложение будет работать быстрее и эффективнее. А увеличение скорости работы хотя бы на несколько процентов, может в перспективе привести к значительным результатам.
Кроме того, есть вероятность, что узким местом вашего приложения может оказаться не серверный код, а его расположение в вашей общей сети. Например, у вас есть API, который подключается к медленной базе данных. И здесь не имеет значения, насколько быстро работает ваш веб-сервер, если он всегда долго ждет результатов. Профилировщики производительности могут помочь решить проблемы только в рамках вашего кода, но никак не в общей сетевой структуре.
Как работает профилирование?
Инструменты профилирования производительности немного отличны от инструментов отладки. IDE использует такие инструменты отладки, как точки останова и инспектирование, для тестирования и решения проблем в процессе разработки. Профилировщики обычно работают, предполагая, что вы не знаете, в чем заключается проблема, и хотите
профилировать код целиком
, чтобы ее выявить. Профилировщик подключается к вашему приложению и с помощью высокоточного таймера отслеживает, какие функции работают дольше всего. Спустя какое-то время у вас будет достаточное количество данных, чтобы понять причину проблемы.
Большая часть профилировщиков представляют данные в виде стека, отсортированного по «потребителям» с наибольшим временем. Чаще всего в профилировщике используют Flame graph, который наглядно отображает разбиение всей истории вызовов программы.
Выбор определенного инструмента или метода зависит от того, для какого языка программирования или для какой среды выполнения кода вы профилируете, и от того, требуется ли вам профилирование приложения в производственных средах или нет, но в общих чертах идея одна и та же.
Так как каждый профилировщик должен быть интегрирован в исполняемый код, то вам необходимо будет загрузить профилировщик для языка, который использует ваше приложение. Некоторые из них проще в использовании, нежели другие, особенно это касается таких языков, как C# и Java. Профилировщик проще внедрить в приложение, которое использует именно эти языки, а не компилируемые.
Многие IDE имеют инструменты профилирования, которые встроены поверх стандартного набора инструментов отладки. Их вы также можете использовать. Например, Visual Studio может профилировать производительность и использование памяти во многих приложениях.
Java –
JProfiler
, IDEA/Eclipse/Netbeans IDEs
Python –
cProfiler
,
Palanteer
JavaScript –
Chrome DevTools
C# –
dotTrace
, Visual Studio IDE
C, C++ –
Orbit
Если вы уже примерно знаете, что может занимать времени больше, чем положено, то вы всегда можете воспользоваться библиотекой, которая имеет в своем арсенале секундомер, для того, чтобы провести оценку производительности.
Например, Benchmark.NET может проводить высокоточные тестирования различных функций и, как правило, используется для сравнения различных алгоритмов. Также можно использовать обычный класс Stopwatch для какого-то фрагмента кода, который вы хотите протестировать.
Использование профилировщика производительности
В этом руководстве мы покажем, как использовать dotTrace. Это полнофункциональный профилировщик производительности для приложений платформы .NET, в котором есть большая часть инструментов, которые есть и в других профилировщиках. Если вы профилируете код, написанный не на C#, то вам, скорее всего, потребуется другое приложение, но общий принцип остается тем же.
Открыв приложение, вы можете подключиться к запущенным .NET процессам или настроить свою собственную конфигурацию запуска для того, чтобы вы могли запускать приложение прямо из dotTrace. Запуск приложения непосредственно из профилировщика может оказаться довольно полезным, если вы пытаетесь устранить проблему, связанную с медленным запуском приложения.
Как только вы запустите приложение, профилировщик начнет собирать данные. Он может работать столько, сколько вы захотите, а для того, чтобы открыть анализ за накопленный период времени, вам нужно просто нажать «Get Snapshot and Wait».
Как только он откроется, вы увидите большое количество графиков рядом со стеком и деревом вызовов, которые, и, скорее всего, они будут нечитабельными. Если вы видите много всего, связанного с потоками, блокировками и ожиданием, то это, скорее всего, потому, что вам нужно оценить «основной поток».
Профилировщик перехватывает все потоки, которые часто используются для фоновых задач и которые простаивают в течение длительного периода времени. Несмотря на то, что это может говорить о проблемах с блокировкой ввода-вывода, здесь все куда более неоднозначно, чем вы можете себе представить, и это действительно зависит от того, какие действия выполняет поток.
dotTrace также имеет функцию фильтрации кода с точки зрения области, в которой он работает. Для этого используются фильтры «Subsystems» слева. Там можно найти системный код (system code), машинный код (native code) и другие запаздывающие области, такие как отражение (reflection), коллекции (collections), строки (string) и LINQ.
В главном окне вы можете найти Flame graph. Он показывает разбиение всего вашего приложения, начиная с «All Calls» (все вызовы) и разбивая дальше время, которое требуется на выполнение каждого уровня функций. Некоторые из них будут неразрешенными, а некоторые будут слишком малы, чтобы отобразить их на графике, но его можно увеличить до любого масштаба, чтобы увидеть любую функцию и более детальное разбиение стека вызовов.
Еще одна важная функция профилировщиков производительности – это дерево вызовов. Оно показывает вложенное разбиение самых быстрых функций, отсортированных по времени, которое необходимо для их выполнения. Здесь dotTrace также показывает процентное соотношение, то есть долю общего времени, которое данная функция и ее дочерние элементы тратят на свое выполнение.
Затраченное время ЦП не всегда является проблемой, особенно есть речь идет о таком языке, как C#, и если у него есть программы сборки мусора. dotTrace также отслеживает использование и распределение памяти, и его можно использовать для того, чтобы определить, что оказывает нежелательную нагрузку на вашу программу сборки мусора.