По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Linux поддерживает множество файловых систем, таких как ext4, ZFS, XFS, Btrfs, Reiser4 и другие. Различные типы файловых систем решают разные проблемы, и их использование зависит от приложения. Что такое файловая система Linux Почти каждый бит данных и программ, необходимых для загрузки системы Linux и поддержания ее работы, сохраняется в файловой системе. Например, сама операционная система, компиляторы, прикладные программы, разделяемые библиотеки, файлы конфигурации, файлы журналов, точки монтирования мультимедиа и т.д. Файловые системы работают в фоновом режиме. Как и остальная часть ядра операционной системы, они практически невидимы при повседневном использовании. Файловая система Linux обычно представляет собой встроенный уровень операционной системы Linux, используемый для управления данными хранилища. Он контролирует, как данные хранятся и извлекаются. Он управляет именем файла, размером файла, датой создания и другой информацией о файле. Файловая система ext4 В 1992 году была запущена файловая Extended File System или ext специально для операционной системы Linux. Она уходит своими корнями в операционную систему Minix. В 1993 году было выпущено обновление под названием Extended File System 2 или ext2, которое в течение многих лет было файловой системой по умолчанию во многих дистрибутивах Linux. К 2001 году ext2 была обновлена до ext3, которая ввела журналирование для защиты от повреждений в случае сбоев или сбоев питания. Ext4 была представлена в 2008 году и является файловой системой Linux по умолчанию с 2010 года. Она была разработана как прогрессивная версия файловой системы ext3 и преодолевает ряд ограничений в ext3. Она имеет значительные преимущества перед своим предшественником, такие как улучшенный дизайн, лучшая производительность, надежность и новые функции. В настоящее время ext4 является файловой системой по умолчанию в большинстве дистрибутивов Linux. Она может поддерживать файлы и файловые системы размером до 16 терабайт. Она также поддерживает неограниченное количество подкаталогов (файловая система ext3 поддерживает только до 32 000). Кроме того, ext4 обратно совместима с ext3 и ext2, что позволяет монтировать эти старые версии с драйвером ext4. Есть причина, по которой ext4 является выбором по умолчанию для большинства дистрибутивов Linux. Она опробована, протестирована, стабильна, отлично работает и широко поддерживается. Если вам нужна стабильность, ext4 - лучшая файловая система Linux для вас. Однако несмотря на все свои функции, ext4 не поддерживает прозрачное сжатие, прозрачное шифрование или дедупликацию данных. Файловая система XFS XFS - это высокомасштабируемая файловая система, разработанная Silicon Graphics и впервые развернутая в операционной системе IRIX на базе Unix в 1994 году. Это файловая система с журналированием которая отслеживает изменения в журнале перед фиксацией изменений в основной файловой системе. Преимущество заключается в гарантированной целостности файловой системы и ускоренном восстановлении в случае сбоев питания или сбоев системы. Первоначально XFS была создана для поддержки чрезвычайно больших файловых систем с размерами до 16 эксабайт и размером файлов до 8 эксабайт. Она имеет долгую историю работы на больших серверах и массивах хранения. Одной из примечательных особенностей XFS является гарантированная скорость ввода-вывода. Это позволяет приложениям зарезервировать пропускную способность. Файловая система рассчитывает доступную производительность и корректирует свою работу в соответствии с существующими резервированиями. XFS имеет репутацию системы, работающей в средах, требующих высокой производительности и масштабируемости, и поэтому регулярно оценивается как одна из самых производительных файловых систем в больших системах с корпоративными рабочими нагрузками. Сегодня XFS поддерживается большинством дистрибутивов Linux и теперь стала файловой системой по умолчанию в Red Hat Enterprise Linux, Oracle Linux, CentOS и многих других дистрибутивах. Лучшие варианты использования файловой системы XFS У вас большой сервер? У вас большие требования к хранилищу или у вас есть локальный медленный диск SATA? Если и ваш сервер, и ваше устройство хранения большие и нет необходимости уменьшать размер файловой системы, XFS, вероятно, будет лучшим выбором. XFS - отличная файловая система, которая хорошо масштабируется для больших серверов. Но даже с меньшими массивами хранения XFS работает очень хорошо, когда средние размеры файлов велики, например, размером в сотни мегабайт. Файловая система btrfs Btrfs - это файловая система Linux общего назначения нового поколения, которая предлагает уникальные функции, такие как расширенное интегрированное управление устройствами, масштабируемость и надежность. Он распространяется под лицензией GPL и открыт для внесения вклада кем угодно. Для файловой системы используются разные имена, в том числе «Butter FS», «B-tree FS» и «Better FS». Разработка Btrfs началась в Oracle в 2007 году. Она была объединена с основным ядром Linux в начале 2009 года и дебютировала в версии Linux 2.6.29. Btrfs не является преемником файловой системы ext4 по умолчанию, используемой в большинстве дистрибутивов Linux, но предлагает лучшую масштабируемость и надежность. Btrfs - это файловая система с копированием при записи (Copy-on-Write - CoW), предназначенная для устранения различных недостатков в текущих файловых системах Linux. Основное внимание уделяется отказоустойчивости, самовосстановлению и простоте администрирования. Btrfs может поддерживать до 16 эксбибайт раздела и файл того же размера. Если вас смущают цифры, все, что вам нужно знать, это то, что Btrfs может поддерживать до шестнадцати раз больше данных Ext4. Как работает Copy-on-Write и зачем вам это нужно В традиционной файловой системе при изменении файла данные считываются, изменяются, а затем записываются обратно в то же место. В файловой системе с копией при записи он считывает данные, изменяет их и записывает в новое место. Это предотвращает потерю данных во время транзакции чтения-изменения-записи, поскольку данные всегда находятся на диске. Поскольку вы не «перенаправляете» до тех пор, пока новый блок не будет полностью записан, если пропадет питание или выйдет из строя в середине записи, вы получите либо старый блок, либо новый блок, но не наполовину записанный поврежденный блокировать. Таким образом, вам не нужно проверять файловые системы при запуске, и вы снижаете риск повреждения данных. Вы можете сделать снимок файловой системы в любой момент, создав запись снимка в метаданных с текущим набором указателей. Это защищает старые блоки от последующего сбора мусора и позволяет файловой системе представить том в том виде, в котором он был во время моментального снимка. Другими словами, у вас есть возможность мгновенного отката. Вы даже можете клонировать этот том, чтобы сделать его доступным для записи на основе снимка. Особенности Btrfs Copy-on-Write и создание снепшотов - Сделайте инкрементное резервное копирование безболезненным даже из файловой системы в процессе работы или виртуальной машины (VM). Контрольные суммы на уровне файла - метаданные для каждого файла включают контрольную сумму, которая используется для обнаружения и исправления ошибок. Сжатие - файлы можно сжимать и распаковывать "на лету", что увеличивает скорость чтения. Автоматическая дефрагментация - файловые системы настраиваются фоновым потоком, пока они используются. Подтомы - файловые системы могут совместно использовать единый пул пространства вместо того, чтобы помещаться в свои собственные разделы. RAID - Btrfs выполняет свои собственные реализации RAID, поэтому LVM или mdadm не требуются для наличия RAID. В настоящее время поддерживаются RAID 0, 1 и 10. RAID 5 и 6 считаются нестабильными. Разделы необязательны - хотя Btrfs может работать с разделами, он может напрямую использовать необработанные устройства (/dev/<device>). Дедупликация данных - поддержка дедупликации данных ограничена; однако дедупликация со временем станет стандартной функцией Btrfs. Это позволяет Btrfs экономить место, сравнивая файлы через двоичные файлы diff. Хотя это правда, что Btrfs все еще считается экспериментальным и в настоящее время находится в активной разработке, время, когда Btrfs станет файловой системой по умолчанию для систем Linux, приближается. Некоторые дистрибутивы Linux уже начали переходить на него в своих текущих выпусках. Файловая система ZFS ZFS (Zettabyte File System) остается одной из наиболее технически продвинутых и полнофункциональных файловых систем с момента ее появления в октябре 2005 года. Это локальная файловая система (например, ext4) и менеджер логических томов (например, LVM), созданные Sun Microsystems. ZFS публиковалась под лицензией с открытым исходным кодом, пока Oracle не купила Sun Microsystems и не закрыла лицензию. Вы можете думать о ZFS как о диспетчере томов и как о RAID-массиве одновременно, что позволяет добавлять дополнительные диски к вашему тому ZFS, что позволяет одновременно добавить дополнительное пространство в вашу файловую систему. В дополнение к этому ZFS обладает некоторыми другими функциями, которых нет в традиционных RAID. ZFS сильно зависит от памяти, поэтому для запуска вам потребуется не менее 8 ГБ. На практике используйте столько, сколько можете получить в соответствии с вашим аппаратным обеспечением или бюджетом. ZFS обычно используется сборщиками данных, пользователями NAS и другими гиками, которые предпочитают полагаться на собственную избыточную систему хранения, а не на облако. Это отличная файловая система для управления несколькими дисками с данными, которая может соперничать с некоторыми из лучших конфигураций RAID. ZFS похожа на другие подходы к управлению хранилищем, но в некотором смысле радикально отличается. ZFS обычно не использует Linux Logical Volume Manager (LVM) или разделы диска, и обычно удобно удалять разделы и структуры LVM перед подготовкой носителя для zpool. Zpool - это аналог LVM. Zpool охватывает одно или несколько устройств хранения, а члены zpool могут быть нескольких различных типов. Основные элементы хранения - одиночные устройства, зеркала и raidz. Все эти элементы хранения называются vdevs. ZFS может обеспечить целостность хранилища намного лучше, чем любой RAID-контроллер, поскольку он досконально знает структуру файловой системы. Безопасность данных - важная особенность конструкции ZFS. Все блоки, записанные в zpool, тщательно проверяются контрольной суммой для обеспечения согласованности и правильности данных. Для использования на сервере, где вы хотите почти полностью исключить любую возможность потери данных и стабильности, вы можете изучить ZFS. Возможности ZFS Бесконечная масштабируемость. Что ж, технически она не бесконечна, но это 128-битная файловая система, способная управлять зеттабайтами (одним миллиардом терабайт) данных. Поэтому независимо от того, сколько у вас места на жестком диске, ZFS подойдет для управления им. Максимальная целостность. Все, что вы делаете внутри ZFS, использует контрольную сумму для обеспечения целостности файла. Вы можете быть уверены, что ваши файлы и их резервные копии не испытают скрытого повреждения данных. Кроме того, пока ZFS незаметно проверяет целостность ваших данных, она будет выполнять автоматическое восстановление в любое время. Объединение дисков. Создатели ZFS хотят, чтобы вы думали об этом как о том, как ваш компьютер использует оперативную память. Когда вам нужно больше памяти на вашем компьютере, вы вставляете другую карту, и все готово. Точно так же с ZFS, когда вам нужно больше места на жестком диске, вы вставляете другой жесткий диск, и все готово. Не нужно тратить время на разбиение на разделы, форматирование, инициализацию или что-то еще с вашими дисками. Если вам нужен «пул» хранилища большего размера, просто добавьте диски. RAID. ZFS поддерживает множество различных уровней RAID, обеспечивая при этом производительность, сравнимую с производительностью аппаратных RAID-контроллеров. Это позволяет сэкономить деньги, упростить настройку и получить доступ к превосходным уровням RAID, которые были улучшены в ZFS. Файловая система Reiser4 ReiserFS - это файловая система общего назначения с журналированием, первоначально разработанная и реализованная командой Namesys во главе с Хансом Райзером. Представленная в версии 2.4.1 ядра Linux, это была первая файловая система с журналированием, включенная в стандартное ядро. За исключением обновлений безопасности и исправлений критических ошибок, Namesys прекратила разработку ReiserFS. Reiser4 является преемницей файловой системы ReiserFS. Добавилось шифрование, улучшил производительность и многое другое. Reiser4 обеспечивает наиболее эффективное использование дискового пространства среди всех файловых систем во всех сценариях и рабочих нагрузках. ReiserFS предлагает преимущества перед другими файловыми системами, особенно когда дело доходит до обработки большого количества небольших файлов. Она поддерживает ведение журнала для быстрого восстановления в случае возникновения проблем. Структура файловой системы основана на деревьях. Кроме того, Reiser4 потребляет немного больше ресурсов ЦП, чем другие файловые системы. Reiser4 обладает уникальной способностью оптимизировать дисковое пространство, занимаемое небольшими файлами (менее одного блока). Они полностью хранятся в своем индексном дескрипторе, без выделения блоков в области данных. Помимо реализации традиционных функций файловой системы Linux, reiser4 предоставляет пользователям ряд дополнительных возможностей: прозрачное сжатие и шифрование файлов, полное ведение журнала данных, а также практически неограниченную (с помощью архитектуры подключаемых модулей) расширяемость. Однако в настоящее время нет поддержки прямого ввода-вывода (началась работа по реализации), квот и POSIX ACL.
img
Перед началом, советуем почитать материал про плоскость управления. Топология - это набор связей (или ребер) и узлов, которые описывают всю сеть. Обычно топология описывается и рисуется как граф, но она также может быть представлена в структуре данных, предназначенной для использования машинами, или в дереве, которое обычно предназначено для использования людьми. Топологическую информацию можно обобщить, просто сделав так, чтобы пункты назначения, которые физически (или виртуально) соединены на расстоянии нескольких прыжков, казались непосредственно присоединенными к локальному узлу, а затем удалив информацию о связях и узлах в любой маршрутной информации, переносимой в плоскости управления, с точки суммирования. Рисунок 4 иллюстрирует эту концепцию. Изучение топологии Казалось бы, достаточно просто узнать о топологии сети: изучить подключенные каналы передачи данных. Однако то, что кажется простым в сетях, часто оказывается сложным. Изучение локального интерфейса может рассказать вам о канале, но не о других сетевых устройствах, подключенных к этому каналу. Кроме того, даже если вы можете обнаружить другое сетевое устройство, работающее с той же плоскостью управления по определенному каналу, это не означает, что другое устройство может вас обнаружить. Таким образом, необходимо изучить несколько вопросов. Обнаружение других сетевых устройств Если маршрутизаторы A, B и C подключены к одному каналу, как показано на рисунке 5, какие механизмы они могут использовать для обнаружения друг друга, а также для обмена информацией о своих возможностях? Первое, что следует отметить в отношении сети, показанной в левой части рисунка 5, - это то, что интерфейсы не соответствуют соседям. Фактические отношения соседей показаны в правой части рисунка 5. У каждого маршрутизатора в этой сети есть два соседа, но только один интерфейс. Это показывает, что плоскость управления не может использовать информацию об интерфейсе для обнаружения соседей. Должен быть какой-то другой механизм, который плоскость управления может использовать для поиска соседей. Ручная настройка - одно из широко распространенных решений этой проблемы. В частности, в плоскостях управления, предназначенных для перекрытия другой плоскости управления, или плоскостях управления, предназначенных для построения отношений соседства через несколько маршрутизируемых переходов по сети, ручная настройка часто является самым простым доступным механизмом. С точки зрения сложности, ручная настройка очень мало добавляет к самому протоколу. Например, нет необходимости в какой-либо форме многоадресного объявления соседей. С другой стороны, ручная настройка соседей требует настройки информации о соседях, что увеличивает сложность с точки зрения конфигурации. В сети, показанной на рисунке 5, маршрутизатор A должен иметь отношения соседства, настроенные с помощью B и C, маршрутизатор B должен иметь отношения соседства, настроенные с помощью A и C, а маршрутизатор C должен иметь отношения соседства, настроенные с помощью A и B. Даже если настройка соседей автоматизирована, ручная настройка углубляет и расширяет поверхности взаимодействия между плоскостями управления и контроля. Определение соседей из маршрутных объявлений - это решение, которое когда-то было широко распространено, но стало менее распространенным. В этой схеме каждое устройство периодически объявляет информацию о доступности и / или топологии. Когда маршрутизатор впервые получает информацию о маршрутизации от другого устройства, он добавляет удаленное устройство в локальную таблицу соседей. Пока соседнее устройство продолжает отправлять информацию о маршрутизации на регулярной основе, отношения между соседями будут считаться активными или активными. При выводе соседей из объявлений о маршрутизации важно иметь возможность определить, когда сосед вышел из строя (чтобы информация о достижимости и топологии, полученная от соседа, могла быть удалена из любых локальных таблиц). Наиболее распространенный способ решения этой проблемы - использование пары таймеров: таймера задержки или отключения и таймера обновления или объявления. Пока сосед отправляет обновление или объявление в пределах таймера отключения или задержки, он считается включенным или активным. Если весь "мертвый" период проходит без получения каких-либо обновлений, сосед считается "мертвым", и предпринимаются некоторые действия, чтобы либо проверить информацию о топологии и доступности, полученную от соседа, либо он просто удаляется из таблицы. Нормальная взаимосвязь между таймером отключения и таймером обновления составляет 3× - таймер отключения установлен на трехкратное значение таймера обновления. Следовательно, если сосед не отправляет три подряд обновления или объявления, таймер бездействия активируется и начинает обработку неработающего соседа. Явные приветствия являются наиболее распространенным механизмом обнаружения соседей. Пакеты приветствия передаются на основе таймера приветствия, и сосед считается "мертвым", если приветствие не получено в течение интервала таймера ожидания или объявления. Это похоже на таймеры dead и update, используемые для вывода соседей из объявлений маршрутизации. Приветствия обычно содержат информацию о соседней системе, такую как поддерживаемые возможности, идентификаторы уровня устройства и т. д. Централизованная регистрация - это еще один механизм, который иногда используется для обнаружения и распространения информации о соседних устройствах. Каждое устройство, подключенное к сети, будет отправлять информацию о себе в какую-либо службу и, в свою очередь, узнавать о других устройствах, подключенных к сети, из этой централизованной службы. Конечно, эту централизованную службу нужно каким-то образом обнаружить, что обычно осуществляется с помощью одного из других упомянутых механизмов. Обнаружение двусторонней связи В плоскостях управления с более сложными процессами формирования смежности - особенно протоколами, которые полагаются на приветствия для формирования отношений соседства - важно определить, могут ли два маршрутизатора видеть друг друга (осуществлять двустороннюю связь), прежде чем формировать отношения. Обеспечение двусторонней связи не только предотвращает проникновение однонаправленных каналов в таблицу пересылки, но также предотвращает постоянный цикл формирования соседей - обнаружение нового соседа, построение правильных локальных таблиц, объявление о доступности новому соседу, тайм-аут ожидания hello или другую информацию, удаление соседа или поиск нового соседа. Существует три основных варианта управления двусторонним подключением между сетевыми устройствами. Не утруждайте себя проверкой двусторонней связи. Некоторые протоколы не пытаются определить, существует ли двусторонняя связь между сетевыми устройствами в плоскости управления, а скорее предполагают, что сосед, от которого принимаются пакеты, также должен быть доступен. Перенос списка доступных соседей, услышанных на линии связи. Для протоколов, которые используют приветствия для обнаружения соседей и поддержания работоспособности, перенос списка доступных соседей по одному и тому же каналу является распространенным методом обеспечения двусторонней связи. Рисунок 6 иллюстрирует это. На рисунке 6 предположим, что маршрутизатор A включен раньше B. В этом случае: A отправит приветствия с пустым списком соседей, поскольку он не получил приветствия от любого другого сетевого устройства по каналу. Когда B включен, он получит приветствие A и, следовательно, включит A в список соседей, которые он слышал в своих hello пакетах. Когда A получает приветствие B, он, в свою очередь, включает B в свой список "услышанных" соседей в своих пакетах приветствия. Когда и A, и B сообщают друг о друге в своих списках соседей, которые "слышно от", оба маршрутизатора могут быть уверены, что двустороннее соединение установлено. Этот процесс часто называют трехсторонним рукопожатием, состоящим из трех шагов: A должен послать привет B, чтобы B мог включить A в свой список соседей. B должен получить приветствие A и включить A в свой список соседей. A должен получить приветствие B с самим собой (A) в списке соседей B. Положитесь на базовый транспортный протокол. Наконец, плоскости управления могут полагаться на базовый транспортный механизм для обеспечения двусторонней связи. Это необычное решение, но есть некоторые широко распространенные решения. Например, протокол Border Gateway Protocol (BGP), опирается на протокол управления передачей (TCP), чтобы обеспечить двустороннюю связь между спикерами BGP. Определение максимального размера передаваемого блока (MTU) Для плоскости управления часто бывает полезно выйти за рамки простой проверки двусторонней связи. Многие плоскости управления также проверяют, чтобы максимальный размер передаваемого блока (MTU) на обоих интерфейсах канала был настроен с одинаковым значением MTU. На рисунке 7 показана проблема, решаемая с помощью проверки MTU на уровне канала в плоскости управления. В ситуации, когда MTU не совпадает между двумя интерфейсами на одном канале, возможно, что соседние отношения сформируются, но маршрутизация и другая информация не будут передаваться между сетевыми устройствами. Хотя многие протоколы имеют некоторый механизм для предотвращения использования информации о результирующих однонаправленных каналах при вычислении путей без петель в сети, все же полезно обнаруживать эту ситуацию, чтобы о ней можно было явным образом сообщить и исправить. Протоколы плоскости управления обычно используют несколько методов, чтобы либо явно обнаружить это условие, либо, по крайней мере, предотвратить начальные этапы формирования соседей. Протокол плоскости управления может включать локально настроенный MTU в поле в пакетах приветствия. Вместо того чтобы просто проверять наличие соседа во время трехстороннего рукопожатия, каждый маршрутизатор может также проверить, чтобы убедиться, что MTU на обоих концах линии связи совпадает, прежде чем добавлять новое обнаруженное сетевое устройство в качестве соседа. Другой вариант - добавить пакеты приветствия к MTU локального интерфейса. Если дополненный пакет приветствия максимального размера не получен каким-либо другим устройством в канале связи, начальные этапы отношений соседства не будут завершены. Трехстороннее рукопожатие не может быть выполнено, если оба устройства не получают пакеты приветствия друг друга. Наконец, протокол плоскости управления может полагаться на базовый транспорт для регулирования размеров пакетов, чтобы коммуникационные устройства могли их принимать. Этот механизм в основном используется в плоскостях управления, предназначенных для наложения какой-либо другой плоскости управления, особенно в случае междоменной маршрутизации и виртуализации сети. Плоскости управления наложением часто полагаются на обнаружение MTU пути (Path MTU) для обеспечения точного MTU между двумя устройствами, подключенными через несколько переходов. Сам размер MTU может оказать большое влияние на производительность плоскости управления с точки зрения ее скорости сходимости. Например, предположим, что протокол должен передавать информацию, описывающую 500 000 пунктов назначения по многопоточному каналу с задержкой 500 мс, и для описания каждого пункта назначения требуется 512 бит: Если MTU меньше 1000 бит, для плоскости управления потребуется 500 000 циклов туда и обратно для обмена всей базой данных доступных пунктов назначения, или около 500 000 × 500 мс, что составляет 250 000 секунд или около 70 часов. Если MTU составляет 1500 октетов или 12000 битов, плоскости управления потребуется около 21000 циклов туда и обратно для описания всей базы данных доступных пунктов назначения, или около 21000 × 500 мс, что составляет около 175 минут. Важность сжатия такой базы данных с использованием какого-либо оконного механизма для сокращения числа полных обходов, необходимых для обмена информацией о достижимости, и увеличения MTU вполне очевидна. Далее почитайте материал о том, как происходит обнаружение соседей в сетях.
img
Введение Однажды в организации, где я работаю, случился Asterisk Случился не без моего участия, а если быть точным, то я и был главным виновником, и как следствие - главным исполнителем. Напасть была локальной, но достаточно быстро получила широкое распространение, хотя, в отдельных уголках приходилось нести прогресс в массы с применением тяжелой артиллерии и напалма. В итоге Asterisk`ом было охвачено порядка полутора тысяч абонентов. Процесс настройки абонента изначально выглядел следующим образом: Включил телефон, обновил прошивку. Пока он перезагружается, завел абонента на Asterisk (создал запись для регистрации SIP-клиента). Далее, самый очевидный способ настройки телефона - web-интерфейс; набрал в адресной строке браузера IP-адрес телефона, авторизовался, настроил два десятка параметров и готово. На всё ушло 2-3 минуты. Следующий абонент - повторяем. На втором десятке абонентов начало надоедать, появилось желание как-нибудь упростить процесс. Заглянул в настройки: экспорт и импорт конфигурации присутствует; сохранил конфигурацию телефона в файл, заглянул в него - обычный текстовый файл, в котором перечислены параметры с их значениями. Нашел параметры, значения которых менял в web-интерфейсе, причем большинство из этих параметров, хоть и отличается от дефолтных, но одинаково для всех настраиваемых в рамках данной организации телефонов. Таким образом, имея эталонный файл конфигурации и редактируя в нем всего 5-6 строк, я получал конфигурации для остальных телефонов, которые "заливал" в аппараты всё через тот же web-интерфейс. Спустя какое-то время количество абонентов заметно выросло, компания продолжала развиваться, сотрудники мигрировали между подразделениями, увольнялись, появлялись новые, некоторые телефоны выходили из строя, и возня с файлами стала постепенно отнимать много времени и раздражала с каждым днем всё больше. Тут я вспомнил про пункт меню из web-интерфейса, в котором были написаны многообещающие слова "Auto Provision". Обратимся за определением к производителям телефонов. У Dlink или Fanvil мы получим следующее: Auto Provisioning используется для реализации удаленной/автоматической инсталляции, развертывания конфигурационных и некоторых других связанных файлов. Snom дает нам практически такое же: Auto Provisioning может использоваться для предоставления общих и специфических параметров конфигурации на телефоны и для актуализации прошивки. Вроде бы всё устраивает, значит, будем для наших целей отталкиваться от этих определений. Вариантов автоматической настройки предусмотрено несколько, и без долгих терзаний, как наиболее понятный и доступный был выбран следующий: Развертывание конфигурации с tftp сервера, адрес которого телефон будет получать по DHCP в Option 66. Разберемся вкратце, что есть что. TFTP - простой протокол передачи файлов (Trivial File Transfer Protocol). В отличие от FTP основан на транспортном протоколе UDP и в нем отсутствует возможность аутентификации (однако, возможна фильтрация по IP-адресу). Одно из основных преимуществ TFTP - простота реализации клиента, поэтому он достаточно широко используется в частности для загрузки обновлений и конфигураций сетевых устройств. DHCP - протокол динамической настройки узла (Dynamic Host Configuration Protocol); сетевой протокол, позволяющий сетевым устройствам автоматически получать IP-адрес и другие параметры, необходимые для работы в сети TCP/IP. Не вдаваясь глубоко в подробности, схема обмена сообщениями DHCP при получении параметров выглядит следующим образом: DHCPDISCOVER: клиент (в нашем случае, телефон) передает это сообщение broadcast, и использует его для поиска DHCP-серверов в своей канальной среде. В одном из полей этого пакета, в поле options, клиент передает список необходимых ему опций, наиболее распространенными из которых являются: (1) - Subnet Mask (3) - Router (6) - Domain Name Server (15) - Domain Name именно в этом поле клиент сообщает о том, что ему нужен адрес tftp сервера для загрузки конфигурационного и/или других связанных файлов. Номер опции, которая его содержит - 66 (у cisco есть аналогичная опция 150, основное отличие которой в том, что она может содержать адреса нескольких tftp серверов). DHCPOFFER: cервер отвечает на запрос клиента. Сервер может передать это сообщение как broadcast так и unicast (зависит от значений полей полученных от клиента). В этом сообщении сервер предлагает клиенту параметры, которые он может отдать в текущей конфигурации. Если в сегменте сети клиента несколько DHCP серверов, то получив запрос, они все отправляют OFFER-ы. После того, как клиент выбрал, OFFER какого из DHCP серверов принять, он отправляет следующий пакет: DHCPREQUEST: казалось бы, если клиент определился, какой DHCP сервер "пришелся ему по душе", можно передать unicast-запрос этому серверу; однако предается broadcast, чтобы уведомить остальные DHCP серверы о своём выборе (добавляется опция 54, указывающая адрес выбранного DHCP-сервера), и они могли освободить зарезервированные OFFER-ы. DHCPACK: cервер отправляет подтверждение клиенту. После этого клиент настраивает свой сетевой интерфейс, используя предоставленные параметры и опции. В различных ситуациях могут еще возникать DHCPDECLINE, DHCPNAK, DHCPRELEASE, DHCPINFORM, но их рассмотрение в рамки данной статьи не входит. Для получения исчерпывающей информации о работе DHCP можно обратиться к RFC 2131: https://tools.ietf.org/html/rfc2131 Про опции 66 и 150 можно почитать здесь: https://wiki.merionet.ru/ip-telephoniya/67/dhcp-opciya-150-i-66/ https://blog.router-switch.com/2013/03/dhcp-option-150-dhcp-option-66/ Про настройку DHCP сервера и Option 66 на Mikrotik можно почитать здесь: https://wiki.merionet.ru/seti/5/nastrojka-dhcp-servera-na-mikrotik/ Чтобы передать телефону адрес tftp сервера, с которого он может получить конфигурационный файл, на DHCP сервере в параметрах области задаем Option 66, в которой указываем hostname либо IP адрес нашего tftp сервера. Настройки по-умолчанию в большинстве телефонов подразумевают получение IP-адреса по DHCP и запрос Option 66. В итоге, телефон получает IP, получает адрес tftp сервера и пытается "стянуть" оттуда файл своей конфигурации. Согласно документации Dlink, загрузка файла конфигурации происходит следующим образом: Устанавливается соединение с сервером. Проверяется наличие файла с соответствующим именем: - в первую очередь проверяется файл с именем соответствующим аппаратной платформе; - во вторую - соответствующий MAC адресу устройства; - в третью - соответствующий ID устройства; - файл с произвольным именем проверяется либо в последнюю очередь (DHCP option, UpnP) либо в первую, если он явно указан в конфигурации телефона. Проверяется версия конфигурационного файла. Если версия выше, чем текущая на телефоне, файл конфигурации применяется. Как уже говорилось ранее, файл конфигурации представляет собой текстовый документ определенного вида: Первая строка: <<VOIP CONFIG FILE>>Version:2.0002 Для того, чтобы конфигурация была применена, версия файла должна быть выше, нежели текущая на телефоне, инкрементировать требуется последний разряд версии. По-умолчанию версия конфигурации 2.0002 Пример: Текущая версия конфигурации 2.0002 на одном телефоне и 2.0004 на еще двух. Для того чтобы конфигурация применилась только на один телефон в первой строке файла конфигурации ставим <<VOIP CONFIG FILE>>Version:2.0004 для того чтобы обновить конфигурацию на всех телефонах ставим в первой строке <<VOIP CONFIG FILE>>Version:2.0005 Разделы: <GLOBAL CONFIG MODULE - содержит данные о сетевых настройках, серверах DNS, SNTP... <LAN CONFIG MODULE> - содержит данные о настройках LAN, режимах работы LAN <TELE CONFIG MODULE> - настройки расширенных функций телефонной части (Call Feature) <DSP CONFIG MODULE> - настройка кодеков <SIP CONFIG MODULE> - настройки SIP, серверы, регистрация etc... <PPPoE CONFIG MODULE> - настройки PPPoE <MMI CONFIG MODUL>E - настройки доступа и WEB интерфейса <QOS CONFIG MODULE> - qos и vlan <DHCP CONFIG MODULE> - настройки внутреннего DHCP <NAT CONFIG MODULE> - настройки NAT и ALG <PHONE CONFIG MODULE> - настройки телефонной части, в этом же разделе настраивается remote phonebook и extension key. <SCREEN KEY CONFIG MODULE> - настройка программных клавиш (для версии F3) <AUTOUPDATE CONFIG MODULE> - настройки Autoprovision <VPN CONFIG MODULE> - настройки VPN <TR069 CONFIG MODULE> - настройки TR069 Заканчивается файл строкой <<END OF FILE>> Для обновления какой-либо опции конфигурации телефона, чтобы файл конфигурации был принят телефоном достаточно наличие следующих полей: <<VOIP CONFIG FILE>> Version:2.0002 <Название необходимого раздела> Название опции: значение <<END OF FILE>> Например, для обновления имени хоста телефона необходимо создать следующий файл конфигурации: <<VOIP CONFIG FILE>>Version:2.0003 <GLOBAL CONFIG MODULE> Host Name :ReceptionPhone <<END OF FILE>> Все остальные элементы являются необязательными. Итак, овал нарисован. Остались сущие мелочи - реализовать инструмент для создания конфигураций и дальнейшего управления ими. Займемся этим в следующей публикации.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59