По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Предыдущий материал из цикла про ARP в IPv4. Ждет вас по ссылке.
Как хост может узнать, следует ли пытаться отправить пакет хосту через сегмент, к которому он подключен, или отправить пакет на маршрутизатор для дальнейшей обработки? Если хост должен отправлять пакеты на маршрутизатор для дальнейшей обработки, как он может узнать, на какой маршрутизатор (если их несколько) отправлять трафик? Эти две проблемы вместе составляют проблему шлюза по умолчанию.
Для IPv4 проблему довольно легко решить, используя префикс и длину префикса. Рисунок ниже демонстрирует нам это.
Реализации IPv4 предполагают, что любой хост в пределах одной подсети IPv4 должен быть физически подключен к одному проводу. Как реализация может определить разницу? Маска подсети - это еще одна форма длины префикса, которая указывает, где заканчивается сетевой адрес и начинается адрес хоста. В этом случае предположим, что длина префикса равна 24 битам, или сетевой адрес равен /24. 24 указывает вам, сколько битов задано в маске подсети: 24 bits = 11111111.11111111.11111111.0000000
Поскольку в IPv4 используется десятичная запись маски, это также можно записать как 255.255.255.0. Чтобы определить, находится ли C на том же проводе, что и A, A будет:
Логическое умножение маски подсети с адресом локального интерфейса
Логическое умножение маски подсети с адресом назначения
Сравните два результата; если они совпадают, целевой хост находится на том же канале связи, что и локальный интерфейс
На рисунке ниже это продемонстрировано.
На рисунке выше показано четыре IPv4-адреса; предположим, что A должен отправлять пакеты в C, D и E. Если A знает, что длина префикса локального сегмента составляет 24 бита либо с помощью ручной настройки, либо с помощью DHCPv4, то он может просто посмотреть на 24 наиболее значимых бита каждого адреса, сравнить его с 24 наиболее значимыми битами своего собственного адреса и определить, находится ли пункт назначения на сегменте или нет. Двадцать четыре бита IPv4-адреса создают хороший разрыв между третьей и четвертой секциями адреса (каждая секция IPv4-адреса представляет собой 8 бит адресного пространства, в общей сложности 32 бита адресного пространства).
Любые два адреса с такими же левыми тремя секциями, что и у A, называемые сетевым адресом, находятся в одном сегменте; любой адрес, которого нет в сегменте. В этом случае сетевой адрес для A и C совпадает, поэтому A будет считать, что C находится в одном сегменте, и, следовательно, будет отправлять пакеты C напрямую, а не отправлять их на маршрутизатор. Для любого пункта назначения, который A считает вне сегмента, он будет отправлять пакеты на IPv4-адрес конечного пункта назначения, но на MAC-адрес шлюза по умолчанию. Это означает, что маршрутизатор, выступающий в качестве шлюза по умолчанию, примет пакет и переключит его на основе IPv4-адреса назначения. Как выбирается шлюз по умолчанию? Он либо настраивается вручную, либо включается в параметр DHCPv4.
А что насчет D? Поскольку сетевые части адресов не совпадают, A будет считать, что D находится вне сегмента. В этом случае A отправит любой трафик для D на свой шлюз по умолчанию, которым является B. Когда B получит эти пакеты, он поймет, что A и D достижимы через один и тот же интерфейс (на основе своей таблицы маршрутизации), поэтому он будет отправлять ICMP-перенаправление на A, говоря ему, что нужно отправлять трафик на D напрямую, а не через B.
IPv6 представляет собой более сложный набор проблем, которые необходимо решить при выборе шлюза по умолчанию, потому что IPv6 предполагает, что одно устройство может иметь много адресов IPv6, назначенных конкретному интерфейсу. Рисунок ниже демонстрирует это.
На рисунке выше предположим, что администратор сети настроил следующие политики:
Ни один хост не может подключаться к A, если у него нет адреса в диапазоне адресов 2001: db8: 3e8: 110 ::/64.
Ни один хост не может подключиться к D, если у него нет адреса в диапазоне адресов 2001: db8: 3e8: 112 ::/64.
Примечание: В реальном мире вы никогда не построили бы такую политику; это надуманная ситуация, чтобы проиллюстрировать проблему, поставленную в сети минимального размера. Гораздо более реальной проблемой такого же типа была бы одноадресная переадресация обратного пути (uRPF).
Чтобы эти политики работали, администратор назначил 110::3 и 112::12 хосту C и 111::120 хосту F. Это может показаться странным, но совершенно законно для одного сегмента иметь несколько подсетей IPv6, назначенных в IPv6; также совершенно законно иметь одно устройство с несколькими адресами. На самом деле, в IPv6 существует множество ситуаций, когда одному устройству может быть назначен диапазон адресов.
Однако с точки зрения длины префикса нет двух адресов, назначенных C или F, в одной подсети. Из-за этого IPv6 не полагается на длину префикса, чтобы определить, что находится в сегменте, а что нет. Вместо этого реализации IPv6 ведут таблицу всех подключенных хостов, используя запросы соседей, чтобы определить, что находится в сегменте, а что нет. Когда хост хочет отправить трафик из локального сегмента, он отправляет трафик на один из маршрутизаторов, о котором он узнал из объявлений маршрутизатора. Если маршрутизатор получает пакет, к которому, как он знает, другой маршрутизатор в сегменте имеет лучший маршрут (поскольку у маршрутизаторов есть таблицы маршрутизации, которые говорят им, какой путь выбрать к какому-либо конкретному месту назначения), маршрутизатор отправит сообщение перенаправления ICMPv6, сообщающее хосту использовать какой-либо другой маршрутизатор первого перехода для достижения пункта назначения.
В следующей статьей мы поговорим про пакетную коммутацию.
Несмотря на доступ к все более эффективному и мощному оборудованию, операции, выполняемые непосредственно на традиционных физических (или «чистых») серверах, неизбежно сталкиваются со значительными практическими ограничениями. Стоимость и сложность создания и запуска одного физического сервера говорят о том, что эффективное добавление и удаление ресурсов для быстрого удовлетворения меняющихся потребностей затруднено, а в некоторых случаях просто невозможно. Безопасное тестирование новых конфигураций или полных приложений перед их выпуском также может быть сложным, дорогостоящим и длительным процессом.
Исследователи-первопроходцы Джеральд Дж. Попек и Роберт П. Голдберг в статье 1974 года («Формальные требования к виртуализируемым архитектурам третьего поколения» (“Formal Requirements for Virtualizable Third Generation Architectures”) - Communications of the ACM 17 (7): 412–421) предполагали, что успешная виртуализация должна обеспечивать такую среду, которая:
Эквивалента физическому компьютеру, поэтому доступ программного обеспечения к аппаратным ресурсам и драйверам должен быть неотличим от невиртуализированного варианта.
Обеспечивает полный контроль клиента над аппаратным обеспечением виртуализированной системы.
По возможности эффективно выполняет операции непосредственно на базовых аппаратных ресурсах, включая ЦП.
Виртуализация позволяет разделить физические ресурсы вычислений, памяти, сети и хранилища («основополагающая четверка») между несколькими объектами. Каждое виртуальное устройство представлено в своем программном обеспечении и пользовательской среде как реальный автономный объект. Грамотно настроенные виртуальные изолированные ресурсы могут обеспечить более защиту приложений приложений без видимой связи между средами. Виртуализация также позволяет создавать и запускать новые виртуальные машины почти мгновенно, а затем удалять их, когда они перестанут быть необходимыми.
Для больших приложений, поддерживающих постоянно меняющиеся бизнес-требования, возможность быстрого вертикального масштабирования с повышением или понижением производительности может означать разницу между успехом и неудачей. Адаптивность, которую предлагает виртуализация, позволяет скриптам добавлять или удалять виртуальные машины за считанные секунды, а не недели, которые могут потребоваться для покупки, подготовки и развертывания физического сервера.
Как работает виртуализация?
В невиртуальных условиях, архитектуры х86 строго контролируют, какие процессы могут работать в каждом из четырех тщательно определенных уровней привилегий (начиная с Кольца 0 (Ring 0) по Кольцо 3).
Как правило, только ядро операционной системы хоста имеет какой-либо шанс получить доступ к инструкциям, хранящимся в кольце под номером 0. Однако, поскольку вы не можете предоставить нескольким виртуальным машинам, которые работают на одном физическом компьютере, равный доступ к кольцу 0, не вызывая больших проблем, необходим диспетчер виртуальных машин (или «гипервизор»), который бы эффективно перенаправлял запросы на такие ресурсы, как память и хранилище, на виртуализированные системы, эквивалентные им.
При работе в аппаратной среде без виртуализации SVM или VT-x все это выполняется с помощью процесса, известного как ловушка, эмуляция и двоичная трансляция. На виртуализированном оборудовании такие запросы, как правило, перехватываются гипервизором, адаптируются к виртуальной среде и возвращаются в виртуальную машину.
Простое добавление нового программного уровня для обеспечения такого уровня организации взаимодействия приведет к значительной задержке практически во всех аспектах производительности системы. Одним из успешных решений было решение ввести новый набор инструкций в ЦП, которые создают, так называемое, «кольцо 1», которое действует как кольцо 0 и позволяет гостевой ОС работать без какого-либо влияния на другие несвязанные операции.
На самом деле, при правильной реализации виртуализация позволяет большинству программных кодов работать как обычно, без каких-либо перехватов.
Несмотря на то, что эмуляция часто играет роль поддержки при развертывании виртуализации, она все же работает несколько иначе. В то время как виртуализация стремится разделить существующие аппаратные ресурсы между несколькими пользователями, эмуляция ставит перед собой цель заставить одну конкретную аппаратную/программную среду имитировать ту, которой на самом деле не существует, чтобы у пользователей была возможность запускать процессы, которые изначально было невозможно запустить. Для этого требуется программный код, который имитирует желаемую исходную аппаратную среду, чтобы обмануть ваше программное обеспечение, заставив его думать, что оно на самом деле работает где-то еще.
Эмуляция может быть относительно простой в реализации, но она почти всегда несет за собой значительные потери производительности.
Согласно сложившимся представлениям, существует два класса гипервизоров: Type-1 и Type-2.
Bare-metal гипервизоры (исполняемые на «голом железе») (Type-1), загружаются как операционная система машины и – иногда через основную привилегированную виртуальную машину – сохраняют полный контроль над аппаратным обеспечением хоста, запуская каждую гостевую ОС как системный процесс. XenServer и VMWare ESXi – яркие примеры современных гипервизоров Type-1. В последнее время использование термина «гипервизор» распространилось на все технологии виртуализации хостов, хотя раньше оно использовалось только для описания систем Type-1. Первоначально более общим термином, охватывающим все типы систем, был «Мониторы виртуальных машин». То, в какой степени люди используют термин «мониторы виртуальных машин» все это время, наводит меня на мысль, что они подразумевают «гипервизор» во всех его интерпретациях.
Гипервизоры, размещенные на виртуальном узле (Type-2) сами по себе являются просто процессами, работающими поверх обычного стека операционной системы. Гипервизоры Type-2 (включая VirtualBox и, в некотором роде, KVM) отделяют системные ресурсы хоста для гостевых операционных систем, создавая иллюзию частной аппаратной среды.
Виртуализация: паравиртуализация или аппаратная виртуализация
Виртуальные машины полностью виртуализированы. Иными словами, они думают, что они обычные развертывания операционной системы, которые живут собственной счастливой жизнью на собственном оборудовании. Поскольку им не нужно взаимодействовать со своей средой как-то иначе, чем с автономной ОС, то они могут работать с готовыми немодифицированными программными стеками. Однако раньше за такое сходство приходилось платить, потому что преобразование аппаратных сигналов через уровень эмуляции занимало дополнительное время и циклы.
В случае с паравиртуализацией (PV – Paravirtualization) паравиртуальные гости хотя бы частично осведомлены о своей виртуальной среде, в том числе и том, что они используют аппаратные ресурсы совместно с другими виртуальными машинами. Эта осведомленность означает, что хостам PV не нужно эмулировать хранилище и сетевое оборудование, и делает доступными эффективные драйверы ввода-вывода. На первых порах это позволяло гипервизорам PV достигать более высокой производительности для операций, требующих подключения к аппаратным компонентам.
Тем не менее, для того, чтобы предоставить гостевой доступ к виртуальному кольцу 0 (т.е. кольцу -1), современные аппаратные платформы – и, в частности, архитектура Intel Ivy Bridge – представили новую библиотеку наборов инструкций ЦП, которая позволила аппаратной виртуализации (HVM – Hardware Virtual Machine) обойти узкое место, связанное с ловушкой и эмуляцией, и в полной мере воспользоваться преимуществами аппаратных расширений и немодифицированных операций ядра программного обеспечения.
Также значительно повысить производительность виртуализации может последняя технология Intel – таблицы расширенных страниц (EPT – Extended Page Tables).
В связи с этим, в большинстве случаев можно обнаружить, что HVM обеспечивает более высокую производительность, переносимость и совместимость.
Аппаратная совместимость
Как минимум, несколько функций виртуализации требуют аппаратную поддержку, особенно со стороны ЦП хоста. Именно поэтому вы должны убедиться, что на вашем сервере есть все, что вам необходимо для задачи, которую вы собираетесь ему дать. Большая часть того, что вам нужно знать, храниться в файле /proc/cpuinfo и, в частности, в разделе «flags» (флаги) каждого процессора. Однако вам нужно знать, то искать, потому что флагов будет очень много.
Запустите эту команду, чтобы посмотреть, что у вас под капотом:
$ grep flags /proc/cpuinfo
Контейнерная виртуализация
Как мы уже видели ранее, виртуальная машина гипервизора – это полноценная операционная система, чья связь с аппаратными ресурсами «основополагающей четверки» полностью виртуализирована – она думает, что работает на собственном компьютере.
Гипервизор устанавливает виртуальную машину из того же ISO-образа, который вы загружаете и используете для установки операционной системы непосредственно на пустой физический жесткий диск.
Контейнер в свою очередь фактически представляет собой приложение, запускаемое из скриптообразного шаблона, которое считает себя операционной системой. В контейнерных технологиях, таких как LXC и Docker, контейнеры – это не что иное, как программные и ресурсные (файлы, процессы, пользователи) средства, которые зависят от ядра хоста и представления аппаратных ресурсов «основополагающей четверки» (т.е. ЦП, ОЗУ, сеть и хранилище) для всего, то они делают.
Конечно, с учетом того, что контейнеры фактически являются изолированными расширениями ядра хоста, виртуализация Windows (или более старых или новых версий Linux с несовместимыми версиями libc), например, на хосте Ubuntu 16.04 будет сложна или невозможна. Но эта технология обеспечивает невероятно простые и универсальные вычислительные возможности.
Перемещение
Модель виртуализации также позволяет использовать широкий спектр операций перемещения, копирования и клонирования даже из действующих систем (V2V). Поскольку программные ресурсы, определяющие виртуальную машину и управляющие ею, очень легко идентифицировать, то обычно не требуется очень много усилий для дублирования целых серверных сред в нескольких местах и для разных целей.
Иногда это не сложнее, чем создать архив виртуальной файловой системы на одном хосте, распаковать его на другом хосте по тому же пути, проверить основные сетевые настройки и запустить. Большинство платформ предлагают единую операцию командной строки для перемещения гостей между хостами.
Перемещение развертываний с физических серверов на виртуализированные среды (P2V) иногда может оказаться немного сложнее. Даже создание клонированного образа простого физического сервера и его импорт в пустую виртуальную машину может сопровождаться определенными трудностями. И как только все это будет выполнено, вам, возможно, придется внести некоторые корректировки в системную архитектуру, чтобы можно было использовать возможности, предлагаемые виртуализацией, в полную силу. В зависимости от операционной системы, которую вы перемещаете, вам также может потребоваться использование паравиртуализированных драйверов для того, чтобы ОС могла корректно работать в своем «новом доме».
Как и в любых других ситуациях управления сервером: тщательно все продумывайте заранее.
Когда вы разрабатываете какое-то программное обеспечение, вы поначалу можете не задумываться о часовых поясах. Если только вы не живете в стране, которая имеет несколько часовых поясов, например, в США или России.
Не так давно я столкнулся с проблемой, которая была связана с часовыми поясами. Было несколько юнит-тестов, имеющих дело с датами. Они работали в моем офисе во Франции, но не работали в Марокко у новых членов нашей команды.
Вот тот самый юнит-тест, который работает во Франции, но не работает в Марокко.
Для меня это была возможность научиться правильно обрабатывать дату и время в международном программном обеспечении. В этой статье я расскажу о часовых поясах и поделюсь некоторыми правилами, которым нужно следовать.
Краткое введение в часовые пояса
Поскольку земля имеет форму практически сферы, то солнце восходит в Японии, а садится в Америке. Если бы все использовали глобальное время, то, например, 9:00 было бы восходом солнца в Японии, но закатом в Америки. Это было бы не очень удобно.
Для того, чтобы время согласовывалось с фазами солнца, необходимо перейти от глобального времени ко времени в соответствии с вашим местоположением. В результате земной шар разбивается на часовые пояса (time zones), и каждый из них имеет некоторое смещение (offset). Это смещение представляет собой количество минут, которое необходимо добавить к глобальному времени, чтобы получить время вашего часового пояса. Это смещение может быть положительным или отрицательным.
Глобальное время называется UTC, оно расшифровывается как Universal Time Coordinate (всемирное координированное время). Вы также могли слышать о GMT – часовом поясе без смещения.
Например, когда по UTC время 10:50, то в Сан-Франциско – 03:50 со смещением -0700, а в Пекине – 18:50 со смещением +0800. Однако смещение может быть не только в целых часах. Например, смещение Непала составляет +0545.
В придачу к этому смещению, связанному с часовым поясом, в некоторых странах еще дополнительно смещают часы два раза в год. DST, или летнее время, добавляет еще один час к смещению часового пояса перед наступлением летнего времени. Затем часы переводятся обратно зимой. Цель такого смещения заключается в том, чтобы сделать дневное время длиннее.
Самый простой способ определить часовой пояс – использовать базу данных часовых поясов IANA. В результате вы получите строку, такую как Europe/Paris (Европа/Париж), в соответствии с шаблоном Регион/Город. Кроме того, Microsoft поддерживает собственную базу данных часовых поясов Microsoft, которая используется в их операционных системах. Но использование этой базы может вызвать проблемы при запуске кроссплатформенных приложений .NET Core.
IANA по-прежнему остается лучшим вариантом. База данных Microsoft обновляется не так часто, имеет меньшую историю и использует довольно любопытные названия часовых поясов (например, Romantic Standard Time – романтическое стандартное время) и подвержена ошибкам. Например, постарайтесь не перепутать следующее: Arab Standard Time, Arabic Standard Time и Arabian Standard Time.
И последнее: есть множество способов записать дату. К счастью, спецификация ISO 8601 устанавливает общее правило для представления даты.
Ноябрь 11, 2018 в 12:51:43 AM (в часовом поясе UTC+00:00)
2018-11-05T12:51:43Z