По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Третья часть тут
Поскольку трафик в реальном времени начал передаваться по сетям с коммутацией пакетов, QoS стал серьезной проблемой. Передача голоса и видео полагается на то, что сеть способна быстро переносить трафик между хостами (с низкой задержкой) и с небольшими колебаниями межпакетного разнесения (jitter). Дискуссии вокруг QoS фактически начались в первые дни сети с коммутацией пакетов, но достигли высшей точки примерно в то время, когда рассматривался ATM. На самом деле, одним из главных преимуществ ATM была возможность тщательно контролировать способ, которым обрабатывались пакеты, когда они передавались по сети с коммутацией пакетов.
С провалом ATM на рынке, появились два направления идей о приложениях, которые требуют сильного контроля над jitter и delay:
Эти приложения никогда не будут работать в сетях с коммутацией пакетов. Такого рода приложения всегда должны запускаться в отдельной сети.
Это просто поиск правильного набора элементов управления QoS, чтобы позволить таким приложениям работать в сетях с коммутацией пакетов.
Основное, что больше всего волновало большинство провайдеров и инженеров, была голосовая связь, и основной вопрос сводился к следующему: можно ли обеспечить приличную голосовую связь по сети, также передающей большие файлы и другой "nonreal - time" трафик? Были изобретены сложные схемы, позволяющие классифицировать и маркировать пакеты (называемые QoS-маркировкой), чтобы сетевые устройства знали, как правильно их обрабатывать. Картографические системы были разработаны для переноса этих маркировок QoS из одного типа сети в другой, и много времени и усилий было вложено в исследование механизмов массового обслуживания-порядка, в котором пакеты отправляются по интерфейсу. На рис. 1 показана примерная диаграмма одной системы QoS, и сопоставления между приложениями и маркировками QoS будет достаточно, чтобы проиллюстрировать сложность этих систем.
Увеличение скорости связи оказывают двойной эффект на обсуждение QoS:
Более быстрые каналы связи будут (это очевидно) нести больше данных. Поскольку любой отдельный голосовой и видеопоток становится сокращающейся частью общего использования полосы пропускания, необходимость строго сбалансировать использование полосы пропускания между различными приложениями стала менее важной.
Время, необходимое для перемещения пакета из памяти в провод через микросхему, уменьшается с каждым увеличением пропускной способности.
По мере того, как доступная пропускная способность увеличивалась, потребность в сложных стратегиях массового обслуживания для противодействия jitter становилась все менее значимой. Это увеличение скорости было дополнено новыми системами массового обслуживания, которые гораздо эффективнее управляют различными видами трафика, уменьшая необходимость маркировки и обработки трафика детализированным способом.
Такое увеличение пропускной способности часто обеспечивалось переходом от медного волокна к стекловолокну. Оптоволокно не только обеспечивает большую полосу пропускания, но и более надежную передачу данных. Способ построения физических связей также эволюционировал, делая их более устойчивыми к поломкам и другим материальным проблемам. Вторым фактором, увеличивающим доступность полосы пропускания, стал рост Интернета. По мере того, как сети становились все более распространенными и более связанными, отказ одного канала оказывал меньшее влияние на объем доступной полосы пропускания и на потоки трафика по сети.
Поскольку процессоры стали быстрее, появилась возможность разрабатывать системы, в которых отброшенные и задержанные пакеты будут иметь меньшее влияние на качество потока в реальном времени. Увеличение скорости процессора также позволило использовать очень эффективные алгоритмы сжатия, уменьшая размер каждого потока. На стороне сети более быстрые процессоры означали, что control plane могла быстрее вычислять набор loop-free путей через сеть, уменьшая как прямые, так и косвенные последствия сбоев связи и устройств.
В конечном счете, хотя QoS все еще важен, его можно значительно упростить. Четырех-шести очередей часто бывает достаточно для поддержки даже самых сложных приложений. Если требуется больше, некоторые системы теперь могут либо проектировать потоки трафика через сеть, либо активно управлять очередями, чтобы сбалансировать сложность управления очередями и поддержки приложений.
Централизованный Control Plane - есть ли смысл?
В 1990-х годах, чтобы решить многие из предполагаемых проблем с сетями с коммутацией пакетов, таких как сложные плоскости управления и управление QoS, исследователи начали работать над концепцией, называемой активной сетью. Общая идея состояла в том, что плоскость управления для сети с коммутацией пакетов может и должна быть отделена от устройств пересылки, чтобы позволить сети взаимодействовать с приложениями, запущенными поверх нее.
Базовая концепция более четкого разделения плоскостей управления и данных в сетях с коммутацией пакетов была вновь рассмотрена при формировании рабочей группы по переадресации и разделению элементов управления (ForCES) в IETF. Эта рабочая группа в основном занималась созданием интерфейса, который приложения могли бы использовать для установки пересылки информации на сетевые устройства. Рабочая группа была в конечном итоге закрыта в 2015 году, и ее стандарты никогда не применялись широко.
В 2006 году исследователи начали эксперимент с плоскостями управления в сетях с коммутацией пакетов без необходимости кодирования модификаций на самих устройствах- особая проблема, поскольку большинство этих устройств продавались поставщиками как неизменяемые устройства (или black boxes). Конечным результатом стал OpenFlow, стандартный интерфейс, который позволяет приложениям устанавливать записи непосредственно в таблицу пересылки (а не в таблицу маршрутизации). Исследовательский проект был выбран в качестве основной функции несколькими поставщиками, и широкий спектр контроллеров был создан поставщиками и проектами с открытым исходным кодом. Многие инженеры считали, что технология OpenFlow позволила бы реконструировать инженерные сети за счет централизации управления.
В реальности, все будет по-иному-то, что, скорее всего, произойдет в мире сетей передачи данных: лучшие части централизованной control plane будут поглощены существующими системами, а полностью централизованная модель будет выброшена на обочину, оставив на своем пути измененные представления о том, как control plane взаимодействует с приложениями и сетью в целом.
В наше время компьютерные сети получили широчайшее распространение. Сложно представить работу любого учреждения, в котором не было бы доступа в интернет или же локальной компьютерной сети. В последние годы все большие обороты набирает беспроводной доступ в интернет, однако в этой статье речь пойдет о старых добрых проводных соединениях. В частности о витой паре.
Это интересно - в профессиональной среде витую пару называют "патч - корд"
Что такое витая пара?
В народе так называют кабель связи, состоящий из пары (или нескольких пар) скрученных между собой проводов в единой оболочке. Чтобы связать устройства посредством этого кабеля, в большинстве современных устройств предусмотрены восьмиконтактные разъемы 8Р8С. В обиходе их часто называют RJ45, но это ошибочное именование, поскольку RJ45 это другой стандарт связи, со своим коннектором, не совместимым с 8Р8С, хотя и напоминающим последний внешним видом.
Однако, просто обжать коннекторы на концах кабеля это еще не все. Многие администраторы сетей сталкивались с проблемой, когда сигнал не проходит по проводу. В данном случае приходится вынимать из разъемов оба конца витой пары, и сверять порядок проводов между собой. И хорошо, если кабель короткий 3-5 метра. А если он проведен в другое помещение? Для избежания таких ситуаций и были введены стандарты так называемой распиновки витой пары.
Кабели витой пары имеют более десятка стандартов, однако на текущий момент ранние из них неактуальны по причине низкой скорости передачи данных. На текущий момент стандартная витая пара, используемая в большинстве сетевых устройств это 8 изолированных проводов, попарно свитых между собой и заключенных в общую оболочку. Для удобства распиновки каждый провод обозначается своим цветом (далее для иллюстрации схем распиновки используем сокращения):
бело-оранжевый (БО) оранжевый (О);
бело-зеленый (БЗ) зеленый (З);
бело-синий (БС) синий (С);
бело-коричневый (БК) коричневый (К;)
Типы соединений посредством витой пары также разнятся. Это могут быть как прямые соединения (например, для соединения IP-камеры с сервером или коммутатором), так и кросс-соединения (для соединения однотипных устройств, к примеру, чтобы связать ноутбук и компьютер), или консольные соединения (используются для настройки маршрутизатора с ПК, в основном, в оборудовании Cisco). Для каждого типа соединения важно использовать свои стандарты распиновки.
Типы соединений
Для прямых соединений обычно используется два стандарта. По стандарту TIA/EIA-568A распиновка будет следующей:
БЗ-З-БО-С-БС-О-БК-К
Для стандарта TIA/EIA-568B, используемого чаще, применим такой вариант:
БО-О-БЗ-С-БС-З-БК-К
Чтобы создать перекрестное (кросс) соединение, на одном конце кабеля порядок проводов будет таким:
БО-О-БЗ-С-БС-З-БК-К
А на другом таким:
БЗ-З-БО-С-БС-О-БК-К
Отметим, однако, что большинство современных сетевых устройств автоматически определяют метод обжима кабеля и подстраиваются под него, поэтому кросс-соединение в настоящее время утратило актуальность в пользу прямого.
Для консольного соединения необходимо обжимать провода в «зеркальном» порядке на обоих концах. Иными словами, на одном конце схема обжима будет выглядеть так:
БО-О-БЗ-С-БС-З-БК-К
А на другом так:
К-БК-З-БС-С-БЗ-О-БО
Несмотря на развитие в последние годы беспроводной передачи данных, проводные соединения обеспечивают более стабильную и быструю (в большинстве случаев) связь, что позволяет им быть актуальными до сих пор. Соблюдение стандартов распиновки позволит быстрее наладить соединение даже в крупных сетях, а также в будущем даст возможность быстрого устранения неполадок, связанных с выходом кабеля из строя, поскольку слабым местом витой пары обычно остаются соединения с коннекторами.
Apache Maven - это инструмент управления проектами и автоматизации сборки с открытым исходным кодом, основанный на концепции объектной модели проекта (POM – Project Object Model), которая в основном используется для развертывания приложений на основе Java, но также может использоваться в проектах, написанных на C#, Ruby и другиех языках программирования.
В этой статье мы объясним, как установить и настроить последнюю версию Apache Maven в системе CentOS 7 (данная инструкция также работает с дистрибутивом RHEL и Fedora).
Требования:
Недавно развернутый или существующий экземпляр сервера CentOS 7.
Java Development Kit (JDK) - Maven 3.3+ требует JDK 1.7 или выше для выполнения.
Установка OpenJDK 8 в CentOS 7
Java Development Kit (JDK) является основным требованием для установки Apache Maven, поэтому сначала установите Java в системе CentOS 7 из репозитория по умолчанию и проверьте версию с помощью следующих команд.
# yum install -y java-1.8.0-openjdk-devel
# java -version
Если установка прошла успешно то, вы увидите следующий вывод.
openjdk version "1.8.0_141"
OpenJDK Runtime Environment (build 1.8.0_141-b16)
OpenJDK 64-Bit Server VM (build 25.141-b16, mixed mode)
Установка Apache Maven в CentOS 7
Далее перейдите на официальную страницу загрузки Apache Maven и загрузите последнюю версию или используйте следующую команду wget, чтобы загрузить ее в домашний каталог maven ‘/usr/local/src’.
# cd /usr/local/src
# wget http://www-us.apache.org/dist/maven/maven-3/3.5.4/binaries/apache-maven-3.5.4-bin.tar.gz
Настройка среды Apache Maven
Теперь нам нужно сконфигурировать переменные окружения для предварительно скомпилированных файлов Apache Maven в нашей системе, создав файл конфигурации «maven.sh» в каталоге «/etc/profile.d» .
# cd /etc/profile.d/
# vim maven.sh
Добавьте следующую конфигурацию в файл конфигурации «maven.sh».
# Apache Maven Environment Variables
# MAVEN_HOME for Maven 1 - M2_HOME for Maven 2
export M2_HOME=/usr/local/src/apache-maven
export PATH=${M2_HOME}/bin:${PATH}
Теперь сделайте конфигурационный файл «maven.sh» исполняемым, а затем загрузите конфигурацию, выполнив команду «source» .
# chmod +x maven.sh
# source /etc/profile.d/maven.sh
Проверка версии Apache Maven
Чтобы проверить установку Apache Maven, выполните следующую команду.
# mvn --version
И вы должны получить вывод, похожий на следующий:
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T19:33:14+01:00)
Maven home: /usr/local/src/apache-maven
Java version: 9.0.4, vendor: Oracle Corporation, runtime: /opt/java/jdk-9.0.4
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.17.6-1.el7.elrepo.x86_64", arch: "amd64", family: "unix"
Вот и все! Вы успешно установили Apache Maven 3.5.4 в вашей системе CentOS 7.