По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Существует новая тенденция для стандартов проектирования топологии сети - создание быстрой, предсказуемой, масштабируемой и эффективной коммуникационной архитектуры в среде центра обработки данных. Речь идет о топологии Leaf-Spine, о которой мы поговорим в этой статье.
Почему Leaf-Spine?
Учитывая повышенный фокус на массовые передачи данных и мгновенные перемещения данных в сети, стареющие трехуровневые конструкции в центрах обработки данных заменяются так называемым дизайном Leaf-Spine. Архитектура Leaf-Spine адаптируется к постоянно меняющимся потребностям компаний в отраслях big data с развивающимися центрами обработки данных.
Другая модель
Традиционная трехуровневая модель была разработана для использования в общих сетях. Архитектура состоит из Core маршрутизаторов, Aggregation маршрутизаторов (иногда этот уровень называется Distribution) и Access коммутаторов. Эти устройства взаимосвязаны путями для резервирования, которые могут создавать петли в сети. Частью дизайна является протокол Spanning Tree (STP) , предотвращающий петли, однако в этом случае деактивируется все, кроме основного маршрута и резервный путь используется только тогда, когда основной маршрут испытывает перебои в работе.
Введение новой модели
С конфигурацией Leaf-Spine все устройства имеют точно такое же количество сегментов и имеют предсказуемую и согласованную задержку информации. Это возможно из-за новой конструкции топологии, которая имеет только два слоя: слой «Leaf» и «Spine». Слой Leaf состоит из access коммутаторов, которые подключаются к таким устройствам как сервера, фаерволы, балансировщики нагрузки и пограничные маршрутизаторы. Уровень Spine, который состоит из коммутаторов, выполняющих маршрутизацию, является основой сети, где каждый коммутатор Leaf взаимосвязан с каждым коммутатором Spine.
Чтобы обеспечить предсказуемое расстояние между устройствами в этом двухуровневом дизайне, динамическая маршрутизация уровня 3 используется для соединения уровней. Она позволяет определить наилучший маршрут и настроить его с учетом изменения сети. Этот тип сети предназначен для архитектур центров обработки данных, ориентированных на сетевой трафик типа «Восток-Запад» (East-West). Такой трафик содержит данные, предназначенные для перемещения внутри самого центра обработки данных, а не наружу в другую сеть. Этот новый подход является решением внутренних ограничений Spanning Tree с возможностью использования других сетевых протоколов и методологий для достижения динамической сети.
Преимущества Leaf-Spine
В Leaf-Spine сеть использует маршрутизацию 3го уровня. Все маршруты сконфигурированы в активном состоянии с использованием протокола равноудаленных маршрутов Equal-Cost Multipathing (ECMP) . Это позволяет использовать все соединения одновременно, сохраняя при этом стабильность и избегая циклов в сети. При использовании традиционных протоколов коммутации уровня 2, таких как Spanning Tree в трехуровневых сетях, он должен быть настроен на всех устройствах правильно, и все допущения, которые использует протокол Spanning Tree Protocol (STP), должны быть приняты во внимание (одна из простых ошибок, когда конфигурация STP связана с неправильным назначением приоритетов устройства, что может привести к неэффективной настройке пути). Удаление STP между уровнями Access и Aggregation приводит к гораздо более стабильной среде.
Другим преимуществом является простота добавления дополнительного оборудования и емкости. Когда происходит ситуация перегрузки линков, которая называется oversubscription (что означает, что генерируется больше трафика, чем может быть агрегировано на активный линк за один раз) возможность расширять пропускную способность проста - может быть добавлен дополнительный Spine коммутатор и входящие линии могут быть расширены на каждый Leaf коммутатор, что приведет к добавлению полосы пропускания между уровнями и уменьшению перегрузки. Когда емкость порта устройства становится проблемой, можно добавить новый Leaf коммутатор. Простота расширения оптимизирует процесс ИТ-отдела по масштабированию сети без изменения или прерывания работы протоколов коммутации уровня 2.
Недостатки Leaf-Spine
Однако этот подход имеет свои недостатки. Самый заметный из них – увеличение количества проводов в этой схеме, из-за соединения каждого Leaf и Spine устройства. А при увеличении новых коммутаторов на обоих уровнях эта проблема будет расти. Из-за этого нужно тщательно планировать физическое расположение устройств.
Другим основным недостатком является использование маршрутизации уровня 3.Ее использование не дает возможность развертывать VLAN’ы в сети. В сети Leaf-Spine они локализованы на каждом коммутаторе отдельно – VLAN на Leaf сегменте недоступен другим Leaf устройствам. Это может создать проблемы мобильности гостевой виртуальной машины в центре обработки данных.
Применение Leaf-Spine
Веб-приложения со статичным расположением сервера получат преимущество от реализации Leaf-Spine. Использование маршрутизации уровня 3 между уровнями архитектуры не препятствует приложениям веб-масштаба, поскольку они не требуют мобильности сервера. Удаление протокола Spanning Tree Protocol приводит к более стабильной и надежной работе сети потоков трафика East-West. Также улучшена масштабируемость архитектуры. Корпоративные приложения, использующие мобильные виртуальные машины (например, vMotion), создают проблему, когда сервер нуждается в обслуживании внутри центра обработки данных, из-за маршрутизации уровня 3 и отсутствие VLAN. Чтобы обойти эту проблему, можно использовать такое решение, как Software Defined Networking (SDN) , которое создает виртуальный уровень 2 поверх сети Leaf-Spine. Это позволяет серверам беспрепятственно перемещаться внутри центра обработки данных.
Другие решения
В качестве альтернативы маршрутизации уровня 3 топология Leaf-and-Spine может использовать другие протоколы, такие как Transparent Interconnection of Lots of Links (TRILL) или Shortest Path Bridging (SPB) для достижения аналогичной функциональности. Это достигается за счет сокращения использования Spanning Tree и включения ECMP уровня 2, а также поддержки развертывания VLAN между Leaf коммутаторами.
Итог
Сети Leaf-Spine предлагают множество уникальных преимуществ по сравнению с традиционной трехуровневой моделью. Использование маршрутизации 3-го уровня с использованием ECMP улучшает общую доступную пропускную способность, используя все доступные линии. Благодаря легко адаптируемым конфигурациям и дизайну, Leaf-Spine улучшает управление масштабируемостью и контролем над перегрузкой линий. Устранение протокола Spanning Tree Protocol приводит к значительному повышению стабильности сети. Используя новые инструменты и имея способность преодолевать присущие ограничения другими решениям, такими как SDN, среды Leaf-Spine позволяют ИТ-отделам и центрам обработки данных процветать при удовлетворении всех потребностей и потребностей бизнеса.
В сегодняшней статье научимся грамотно «вайпить» устройства MikroTik. Говоря простым языком – чистить и сбрасывать к заводским настройкам.
Казалось бы – ничего особенного, но давайте подумаем, почему это может быть важно. Дело в том, что устройства MikroTik очень рентабельны - некоторые может быть даже скажут неприлично дёшевы - поэтому капитальные затраты на модернизацию сетей, как правило, довольно низкие. Поэтому, в один момент может случиться такая ситуация, когда у вас окажется стопка MikroTik’ов, выведенных из продакшена, которая будет покоиться на полке и собирать пыль. Эти невостребованные устройства, в конечном итоге могут быть переданы кому-нибудь в тест, использоваться в лаборатории или же перепрофилированы под другие нужды.
Оказавшись в «неправильных» руках, роутер MikroTik может раскрыть немало конфиденциальной и чувствительной информации, если её предварительно не стереть. Несмотря на то, что много такой информации скрыто в конфигурации и просто так через консоль до неё не добраться, файлы .rsc, .backup, .rif, которые находятся в файловом хранилище, позволят потенциальному злоумышленнику получить к ней доступ. Этими файлами мы и займёмся в первую очередь.
Итак для того, чтобы удалить эти файлы через консоль вводим следующие команды:
/file
remove [find name~".rif"]
remove [find name~".txt"]
remove [find name~".rsc"]
remove [find name~".backup"]
Можно также воспользоваться утилитой WinBox, для этого в левом меню выберите опцию Files, перед Вами откроется файловое хранилище:
Если файлов слишком много можно воспользоваться фильтром по каждому типу файла - .rsc, .backup, .rif и .txt
Убедитесь, чтобы в файловом хранилище не осталось ни одного файла с форматами, приведёнными выше.
Внимание! Выполнение следующих действий по сбросу конфигурации без предварительной очистки файлового хранилища, показанной выше не удалит файлы с чувствительной информацией!
Теперь нам осталось только стереть конфигурацию устройства, для этого воспользуемся следующей командой:
/system reset-configuration keep-users=no skip-backup=yes
Или же через утилиту WinBox в меню слева откройте System → Reset Configuration
Подтвердите данное действие, после чего устройство удалит конфигурацию, перезагрузится и заново сгенерирует SSH ключи. После всех вышеописанных действий, можно считать, что роутер успешно сброшен к заводским настройкам.
Общий совет – если Вы выводите устройство из эксплуатации и отправляете на полку до лучших времён, то убедитесь в том, что на нём не осталось чувствительной информации, сделайте полный вайп, а его бэкап, на случай, если оно вдруг снова понадобится, храните в яйце яйцо в утке, утку в зайце, зайца в сундуке где-нибудь в другом месте :)
Существует множество различных решений для управления Asterisk, основой которых, является FreePBX. К ним относятся - Elastix, PBX in a Flash (PIAF), Trixbox, AsteriskNOW и FreePBX Distro. Однако, с момента первого релиза FreePBX многое изменилось и большинство перечисленных проектов по-просту перестали существовать. Trixbox перестал поддерживать открытое ПО и переориентировался на коммерческую редакцию Trixbox Pro. Elastix и PIAF вообще дружно сменили свой движок с Asterisk на 3CX и для этих продуктов обновлений также больше нет. Кроме того, есть компании, которые до сих пор используют старые не поддерживаемые версии FreePBX и ежедневно испытывают трудности с их работой, а также те, кто установил FreePBX вручную на не поддерживаемые операционные системы.
Единственный продукт, который до сих пор обновляется и поддерживается разработчиком - это сам проект FreePBX и FreePBX Distro. Принимая это во внимание, разработчики FreePBX создали решение, которое позволяет сделать миграцию любой системы на базе FreePBX, (начиная с версии 2.9 до и включая версию 14) на свеженькую FreePBX Distro на базе ОС SNG 7, со всеми настройками и конфигурацией!
Итак, можно мигрировать с:
Elastix;
PBX in A Flash;
AsteriskNOW;
вручную установленного FreePBX (в том числе установленного на не поддерживаемой ОС);
FreePBX Distro
При этом система, с которой производится миграция не требует остановки эксплуатации или перезагрузки, так как инструмент всего лишь считывает конфигурацию с системы "донора" на свежую систему FreePBX Distro.
Как это работает:
Вам нужно будет установить свежую версию свежую версию FreePBX Distro , на которую будет происходить миграция и активировать её;
Запустить на новом сервере с FreePBX Distro скрипт конвертации командой: curl -s https://convert.freepbx.org | bash
Этой командой сервер запросит место (слот) в очереди на конвертацию. Когда слот будет успешно занят сгенерируется ключ, вида 2beb181b-14ed-4f56-a86b-f6e564ba6c43;
После этого, нужно запустить такую же команду на сервере - доноре, с которого вы хотите мигрировать и ввести полученный ключ;
Конвертер извлечёт необходимые данные с донора и загрузит их на новый сервер. Этот процесс не окажет никого влияния на донора, не внесёт на нем никаких изменений и не потребует выключения;
Скрипт также будет пробовать стянуть с донора всякие кастомные данные, такие как пользовательские голосовые файлы и данные провиженинга;
Все транки на новом сервере будут выключены, чтобы избежать конфликта с зарегистрированными линиями к провайдеру на старом сервере.
О том, как установить FreePBX читайте в нашей статье
Какие данные будут перенесены на новый сервер:
Внутренние номера (Extensions);
Маршруты (Inbound/Outbound Routes);
Линии к провайдеру (Trunks);
Музыка на ожидании (MoH);
Голосовые меню (IVR);
Группы вызова (Ring Groups);
Очереди (Queues);
Любые другие настройки, являющиеся стандартной частью FreePBX;
Звуковые файлы, включая: загруженную пользователем музыку на ожидании (MoH), записи голосовой почты и приветствия для голосовой почты, а также системные записи (System Recordings)
Какие данные не будут перенесены на новый сервер:
История звонков, то есть Call Data Report (CDR) и таблица Call Event Log (CEL);
Вы можете самостоятельно перенести эти данные на новый сервер, экспортируя их с помощью 'mysqldump' или аналогичной утилиты. Эти данные могут быть очень тяжёлыми, поэтому пользователь сам должен позаботиться об их переносе.
Настройки факса;
Эта часть претерпела огромные изменения с момента первого релиза FreePBX, поэтому придется самостоятельно перенастроить почты пользователей, которым нужен функционал факса.
Кастомные изменения конфигурационных файлов;
То есть всё, что было изменено в файлах вида *_custom.conf, например /etc/asterisk/extensions_custom.conf. Если у вас есть такие настройки, то переносить их на новый сервер нужно будет вручную.
Настройки не FreePBXовых модулей;
Ну например Elastix Call Center Module, Queue Metrics и остальные модули, которые не являются стандартными для FreePBX.
В общем и целом, звучит неплохо, правда? Мы можем безболезненно перенести большинство необходимых данных с неподдерживаемой системы и продолжить работу на новой, получая все актуальные обновления. Процесс миграции не представляется чем-то сверх сложным, так что давайте попробуем?
Процесс миграции
Итак, первое с чего нужно начать - это подготовка нового сервера с FreePBX Distro. Важно устанавливать именно 64-битную версию, поскольку 32-битная больше не поддерживается.
О том как установить FreePBX Distro подробно читайте в нашей статье.
Как только FreePBX Distro будет установлен, его необходимо активировать. Активация требуется для того чтобы сгенерировать криптографический ключ для защиты ваших данных для передачи на сервер конвертации https://convert.freepbx.org.
Данные передаются в зашифрованном виде, чтобы исключить возможность их утечки в случае атаки типа Man-in-the-Middle.
Затем необходимо настроить NAT. FreePBX Distro имеет свой встроенный модуль Firewall, который автоматически настраивает параметры NAT и Firewall через специальный помощник при первом запуске FreePBX.
О том как настраивать Firewall читайте в нашей статье.
После того как сервер с чистым FreePBX Distro настроен, необходимо зарезервировать слот для конвертации.
Это делается с помощью специального скрипта: curl -s https://convert.freepbx.org | bash. Когда Вам предложат ввести reservation ID, просто нажмите 'Enter'.
По окончанию процесса резервации слота, будет сгенерирован уникальный код конвертации вида: 2beb181b-14ed-4f56-a86b-f6e564ba6c43. Его потом нужно будет ввести на доноре.
После этого, новый сервер будет ожидать ответа от донора. Не останавливайте скрипт, нужно чтобы на экране была надпись Waiting for Donor….
Теперь нужно запустить такую же команду на сервере - доноре, с которого вы хотите мигрировать и ввести полученный ключ;
Возвращаемся на сервер-донор (Elastix, PIAF и так) с которого мы хотим мигрировать и запускаем тот же самый скрипт: curl -s https://convert.freepbx.org | bash
Когда вас попросят ввести ID, введите то что было сгенерировано при запуске скрипта на новом FreePBX Distro.
Это запускает процедуру экспорта всех данных и настроек с сервера донора и создание сжатого, криптографически защищённого архива с этими данными для отправки на новый сервер.
В зависимости от того, насколько давно был развёрнут старый сервер, существует возможность неудачной обработки команды скрипта, поскольку сервер может не поддерживать обработку TLS сертификатов. Если после запуска скрипта ничего не происходит, попробуйте запустить команду с отключением верификации TLS сертификата: curl --insecure https://convert.freepbx.org | bash
Как только процесс завершится, новый сервер будет иметь все настройки и данные, которые были на сервере доноре. Вы получаете полностью рабочий сервер со свежей версией FreePBX Distro, которая будет получать актуальные обновления софта и безопасности со всеми настройками, которые были на старом сервере!