По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Привет! Сегодня в статье мы хотим рассмотреть систему восстановления Cisco Unified Communications Manager (CUCM) после сбоев, которая называется Disaster Recovery System (DRS) . С ее помощью можно делать бэкапы системы, которые будут храниться на SFTP сервере, и восстанавливать из них систему в случае такой необходимости.
Архивирование при помощи DRS включает следующие компоненты:
Cisco Unified Communications Manager database (CCMDB), включая Cisco Unified Communications Manager/CDR Analysis and Reporting/Call Detail Records);
Platform
Music On Hold (MOH);
BAT Bulk Provisioning Service (BPS);
CCM Preference Files (CCMPREFS);
TFTP Phone device files (TFTP);
SNMP Syslog Component (SYSLOGAGT SNMP);
SNMP CDP Subagent (CDPAGT SNMP);
Trace Collection Tool (TCT);
Cluster Manager (CLM);
Cisco Extended Functions (CEF);
Настройка
Прежде всего, для выполнения резервного копирования нам нужно развернуть SFTP сервер. Cisco рекомендует использовать такие клиенты как Cygwin, Titan FTP, GlobalSCAPE EFT, но можно использовать и другие. Загружаем желаемый клиент, устанавливаем его на машине, на которой будет использоваться SFTP сервер, в нем самом настраиваем сетевые параметры подключения, указываем корневую папку и затем запускаем сервис.
Теперь переходим к настройке CUCM. Нам нужно войти в систему восстановления после сбоев, для этого нам нужно в правом верхнем углу из выпадающего меню выбрать пункт Disaster Recovery System.
Здесь переходим во вкладку Backup → Backup Device и нажимаем Add New. В открывшемся окне необходимо указать названия для бэкапа в строке Backup device name. Ниже в поле Select Destination выбираем Network Directory и указываем IP адрес SFTP сервера в строке Host name/IP address, реквизиты для подключения указываем в полях User name и Password, а поле Path name указываем путь для каталога, где будут храниться наши данные (если необходимо хранить файл в корневом каталоге, то указываем ’’’’). После этого нажимаем Save. Если SFTP сервер работает и доступен, то мы увидим надпись Update Successful.
Теперь чтобы создать бэкап нам нужно перейти во вкладку Backup → Manual Backup, выбрать созданные нами ранее настройки резервирования и нажать Start Backup. Создать расписание для выполнения архивирования можно в меню Backup → Scheduler, где нужно нажать Add New для создания нового расписания. Тут выбираем бэкап, указываем время выполнения архивации и нажимаем Save. После чего нажимаем Enable Schedule наверху экрана.
Теперь рассмотрим восстановление системы, которое называется Restoring a Node or Cluster to a Last Known Good Configuration (No Rebuild) , то есть до последней рабочей конфигурации. Для того чтобы восстановить систему из созданного бэкапа нужно перейти во вкладку Disaster Recovery System → Restore → Restore Wizard. Тут выбираем Backup Device, затем нажимаем Next и выбираем один из доступных файлов.
Далее указываем, какие функции должны быть восстановлены.
Затем выбираем нужные серверы для восстановления и нажимаем Restore.
После этого начнется восстановление системы. Статус текущего восстановления можно посмотреть во вкладке Disaster Recovery System → Restore → Status. После того как произойдет восстановление нужно будет перезагрузить сервер. Проверить статус репликации можно либо при помощи RTMT, в пункте Call Manager → Database Summary → Replication Status, где для всех нод мы должны видеть одинаковое значение, либо через систему отчетов CUCM Unified Reporting в пункте Unified Reporting → System Reports → Unified CM Database Status, где мы должны найти строчку All servers have a good replication status, либо через командную строку CLI, выполнив команду utils dbreplication status, результатом которой мы должны получить строчку No Errors or Mismatches found. Replication status is good on all available servers.
Процесс анализа программного кода должен быть максимально автоматизирован. Когда вы создаете запрос на включение изменений, как минимум, вам нужно запустить модульные тесты и статический анализ программного кода в функциональной ветке. Средства автоматизации могут многое рассказать о качестве кода: метрики, покрытие кода модульными тестами, обнаружение дублированных строк и т.д.
Однако есть как минимум 50 вещей, которые нельзя проверить автоматически. Они нуждаются во внимательном взгляде опытного проверяющего (это дает нам хоть какую-то надежду на то, что роботы не заменят разработчиков в ближайшем будущем).
Требования
Программный код реализует все функциональные требования, которые необходимы заказчику?
Программный код удовлетворяет всем нефункциональным требованиям, таким как производительность и безопасность? Если нефункциональные требования не были упомянуты заказчиком, то этот вопрос необходимо уточнить у проектировщика или у самого заказчика.
Условия сопровождения
Помещены ли все интерфейсы, классы и т.д. на соответствующий прикладной уровень в соответствии с архитектурой
Onion/Clean
?
Не изобретаете ли вы колесо, когда пишете программный код? Можно ли его заменить чем-то, что уже существует и что предоставляет какая-либо сторонняя библиотека?
Есть ли уже реализованная логика или какие-то ее фрагменты в кодовой базе?
Правильно ли была выбрана область жизненного цикла для интерфейса и реализации в контейнере внедрения зависимостей?
Являются ли реализованные функции детерминированными (то есть всегда ли они выдают один и тот же результат для одних и тех же входных данных)?
Все ли зависимости явно внедряются через конструктор типов?
Есть ли сильная связанность между классами, которая может затруднить повторное использование кода?
Используются ли
объекты-значения
вместо элементарных типов данных для того, чтобы избежать проблемы одержимости элементарными типами?
Соответствуют ли реализованные компоненты, такие как функции, классы, интерфейсы и модули,
принципу единственной обязанностей
?
Расширяются ли существующие функциональные возможности при помощи декораторов, технологий аспектно-ориентированного программирования (принципа открытия-закрытия) или они модифицируются на месте?
Правильно ли реализованы механизмы синхронизации потоков при доступе к объектам-одиночкам в веб-приложениях?
Используются ли по возможности
неизменяемые типы данных
вместо изменяемых для того, чтобы избежать побочных эффектов?
Добавлена ли функция ведения журнала с верными
уровнями ведения протокола
в основные места кода, которые требуют отслеживания?
Производительность
Правильно ли были выбраны
структуры данных
? Например, используется ли структура Hashtable вместо массива, когда нужно часто искать значения, для того, чтобы избежать линейного поиска?
Распараллелены ли длительные операции между всеми доступными ядрами для того, чтобы использовать ресурсы компьютера максимально эффективного?
Выполняет ли программный код большое количестве
операций по выделению памяти
для объектов в куче, оказывая тем самым дополнительную нагрузку на программу сборки мусора?
Кэшируются
ли данные, которые были считаны из базы данных, локально или в удаленном кэше?
Сколько раз текущий код обращается к базе данных? Возможно стоит получить все данные за одно или несколько обращений?
Выполняет ли код все обращения к базе данных, ввод-вывод и другие блокирующие вызовы асинхронно?
Использует ли код
пул потоков
по максимуму вместо того, чтобы создавать новые потоки?
Правильно ли выбран баланс между
нормализацией
и
денормализацией
при создании дополнительных таблиц базы данных?
Правильно ли добавляются или исправляются индексы, если запрос на включение изменений содержит новые SQL-запросы?
Возникает ли
проблема с N+1 запросами
при извлечении данных из базы данных при помощи фреймворка ORM?
Установлен ли правильный уровень изоляции транзакций в хранимых процедурах?
Возвращают ли SQL-запросы избыточные данные из базы данных, которые не требуются для кода приложения? Используется ли что-то вроде
SELECT *
или что-то подобное?
Модульное и интеграционное тестирование
Полностью ли модульные тесты покрывают дополнительную логику?
При появлении исправлений в логике, появляются ли изменения в соответствующем модульном тесте?
Всегда ли все реализованные модульные или другие виды тестов ведут себя детерминировано? Например, приостанавливают ли они выполнение потока на какой-то определенный период времени перед утверждением (что по своей сути является ошибочным шаблоном)?
Все ли модульные тесты реализованы в соответствии с принципами
F.I.R.S.T.
?
Есть ли какие-либо признаки проблем в модульном тестировании, такие как проблемы с
логикой проверки условий
,
рулеткой с утверждениями
,
дублированием утверждений
и другие?
Добавлен ли интеграционный тест, как минимум, для happy-path-сценария (сценария счастливого пути) реализованной функции?
Все ли зависимости тестируемого объекта имитируются для того, чтобы модульный тест случайно не превратился в интеграционный и не выполнился быстрее положенного?
Изолированы ли модульные и интеграционные тесты друг от друга?
Конечные точки API
Выбираются ли HTTP-команды, такие как
GET, POST, PUT, DELETE
и другие, в соответствии с действием их конечной точки?
Отвечает ли каждая конечная точка API за выполнение лишь одной бизнес-операции? Или все же нескольких?
Возвращает ли конечная точка API правильный код состояния? Например, не возвращает ли она код 401 вместо 500 при несанкционированном запросе?
Сжимаются ли объемные ответы перед их отправкой вызывающей стороне?
Защищены ли конечные точки API политиками аутентификации и авторизации?
Позволяет ли API, который возвращает большой список объектов, фильтровать его и разбивать на страницы?
Является ли конечная точка API GET идемпотентной?
Используются ли имена существительные вместо глаголов в именах конечных точек API?
Критические изменения
Имеются ли в конечной точке API такие критические изменения, как переименование API, удаление или переименование его параметров?
Имеются ли критические изменения в полезных данных сообщения (в случае, если используется брокер сообщений), например, удаление или переименование его свойств?
Повлияют ли такие изменения в схеме базы данных, как удаление столбцов или таблиц, на другие службы системы?
Системная среда
Насколько загружен ЦП и сколько оперативной памяти потребляет код при выполнении запроса на включение изменений? Будет ли в средах, в которых будет развернут код (среда тестирования, среда приёмочного пользовательского тестирования, производственная среда), достаточно мощный процессор и достаточный объем оперативной памяти для эффективного выполнения кода?
Будет ли реализованная логика, алгоритмы, структуры данных и т.д. работать достаточно быстро на большом наборе данных, который может быть в производственной среде?
Документация
Была ли изменена документация для того, чтобы отразить новые изменения программного кода (документация API, документация по структуре, проектная документация)?
Создается ли тикет
технических недоработок
, если запрос на внесение изменений содержит неэффективный или «грязный» код, который сейчас невозможно перестроить из-за недостаточного количества времени?
Заключение
Количество пунктов, на которых проверяющий должен заострить свое внимание, зависит от конкретного проекта и даже от конкретного запроса на внесение изменений. Ваш с коллегами мозговой штурм (если вы примите во внимание вышеприведенные пункты) может значительно снизить риск того, что вы забудете о чем-то важно при анализе программного кода.
Цель данной статьи, чтобы разобраться с тем как поправить незначительные ошибки, возникающие в файловых системах. Файловых систем много, поэтому много различных инструментов для работы с ними. Поэтому будет рассказано об основных инструментах к основным стандартным системам Linux. И рассмотрим несколько инструментов к рекомендованным LPIC файловым системам. Рассмотрим, так же журналируемые файловые системы и посмотрим индексные дескрипторы.
Проверка целостности файловой системы;
Проверка свободного пространства и индексных дескрипторов в файловой системе;
Исправление проблем файловой системы.
Список утилит:
df, du, fsck, debugfs – общие утилиты для всех Linux систем
mke2fs, e2fsck, dumpe2fs, tune2fs – утилиты для файловой системы ext
xfs_check, xfs_repair, xfs_info, xfs_metadump – утилиты для файловой системы xfs
Совершенно понятно, что для других файловых систем есть свои утилиты для работы с данными файловыми сиcтемами.
Первая утилита df:
man df
Данная утилита показывает использование дискового пространства. У данной утилиты достаточно много ключей. Её особенностью является то, что она показывает дисковое пространство в 1 кбайт блоках.
Данные цифры не очень понятны и удобны, для того чтобы было удобно можно использовать ключ –h и тогда вид станет удобно читаемым. В выводе команды мы сразу видим размер, сколько использовано, процент использование и точка монтирования. Как мы видим на новом перемонтированном разделе /dev/sdc1 занят 1% дискового пространства. Если посмотреть в папку монтирования раздела, то мы увидим там папку lost+found. Данная папка пуста, но занимает 37 МБ. Есть такое понятие индексные дескрипторы в журналируемых файловых системах inode. Inode – это метка идентификатора файла или по другому индексный дескриптор. В этих индексных дескрипторах хранится информация о владельце, типе файла, уровне доступа к нему. И нужно понимать, что для каждого файла создается свой отдельный inode. Команда df –I может показать нам inode.
Число, например, inode напротив /dev/sda2 показывает сколько inode всего может быть на устройстве, далее сколько используется и сколько свободно. Обычно под inode отдается примерно 1% жесткого диска. И получается, что больше чем число inode на устройстве файлов и папок быть не может. Количество inode зависит от типа файловой системы. Далее мы рассмотрим, как пользоваться inode.
Следующая команда du
man du
Данная команда показывает, что и сколько занимает у нас места на жестком диске, а именно размер папок в текущей директории. Если посмотреть вывод данной команды без ключей, то мы увидим список папок в текущей директории и количество блоков, с которым очень неудобно работать. Чтобы перевести данные блоки в человеческий вид, то необходимо дать ключ –h.
А для еще большего удобства, можно установить замечательную утилиту ncdu простой командой.
sudo apt install ncdu –y
После установки нужно запустить ncdu. И мы увидим очень красивую картинку.
Но вернемся к стандартной утилите du. С помощью данной утилиты мы можем указать в какой папке необходим просмотр папок и вывод их размера.
du –h /home
К сожалению данная утилита умеет взвешивать вес только каталогов и не показывает размер файлов. Для того, чтобы посмотреть размер файлов, мы конечно же можем воспользоваться командой ls –l. А также если мы запустим данную команду с ключем –i мы увидим номера inode файлов.
Как вы видите у каждой папки и у каждого файла есть свой индексный дескриптор.
Далее команды, которые нам позволят проверить целостность файловой системы.
Команда fsck
man fsck
Как написано в описании утилиты она позволяет проверять и чинить Linux файловую систему.
Мы можем видеть, например, в oперационной системе Windows, что в случае некорректного завершения работы операционной системы, операционная система запускает утилиту проверки целостности checkdisk. В случае необходимости данная утилита исправляет найденные ошибки в файловой системе. Следовательно, в Linux данные операции выполняет утилита fsck, причем может работать с различными файловыми системами Linux операционных систем. Мы можем попробовать воспользоваться утилитой fsck /dev/sdc1. В ответ от операционной системы мы получим следующее:
Как мы видим операционная система вернула в ответ на команду для работы с данным разделом, что данный раздел с монтирован и операция прервана. Аналогичную ситуацию мы будем наблюдать в операционной системе Windows, если мы будем пытаться рабочий раздел проверить на ошибки. Т.е возникнет следующая ситуация. Если мы будем проверять дополнительный логический диск, где не установлена операционная система Windows, то данный раздел на время проведения тестов будет отключен и будут идти проверки. А если мы попытаемся проверить основной раздел, куда установлена операционная система Windows, то операционная система не сможет запустить данную утилиту и попросит перезагрузиться для запуска данной утилиты. В нашем случае придется делать точно так же. Поэтому, чтобы проверить необходимо отключить (от монтировать раздел) и после уже этого запускать утилиту.
Из вывода можно заметить утилита пыталась запустить другую утилиту e2fsck, которая в данном случае отвечает за проверку файловых систем extext2ext3ext4. О чем достаточно подробно написано в описании данной утилиты. По сути fsck запускает утилиту ту, которая идет в пакете утилит для конкретной файловой системы. Бывает такое, что fsck не может определить тип файловой системы.
Для того, чтобы утилита все-таки проверила файловую систему, необходимо отмонтировать логический раздел. Воспользуемся командой umount /mnt.
И запускаем непосредственно саму проверку fsck –t ext4 /dev/sdc1
Проходит проверка моментально. Команда fsck запустилась и запустила необходимую утилиту для файловой системы. По результатам проверки файловая система чистая, найдено 11 файлов и 66753 блока. При обнаружении проблем, утилита предложила нам исправить.
Для того, чтобы посмотреть на проверку другой файловой системы, необходимо переформатировать раздел.
mkfs –t xfs –f /dev/sdc1
При попытке запуска проверки без указания типа файловой системы fsck /dev/sdc1
Как мы видим, утилита fsck отказалась проверять или вызывать утилиту, а явно указала на ту которую необходимо использовать в данном случае. Для проверки используем xfs_ncheck /dev/sdc1. А для починки файловой системы xfs_repair /dev/sdc1.
Перемонтируем обратно наш раздел mount /dev/sdc1 /mnt
Теперь можно получить информацию по разделу xfs_info /dev/sdc1
Или сделать дамп файловой системы xfs_metadump /dev/sdc1 dump.db
Переформатируем файловую систему ext4 на разделе обратно /dev/sdc1. Перемонтируем в папку mnt. Создадим текстовый файл с текстом на данном разделе nano /mnt/test.txt
Далее мы можем посмотреть следующую утилиту man debugfs. Данная утилита умеет очень многое: очень много ключей и различных опций. Чистит, удаляет, чинит, работает с inodes.
Зайти в данную утилиту можно debugfs –w /dev/sdc1. Набираем help и видим кучу опций.
Можно попросить данную утилиту вывести содержимое нашего тома.
ls
В результате данной команды мы увидим 2 объекта с номерами их inode. Теперь мы можем сказать rm test.txt и файл будет удален, точнее не сам файл а его индексный дескриптор., если посмотреть опять с помощью команды ls. То будет видно, что количество объектов не изменилось. Следовательно, мы этот файл в журналируемых файловых системах можем восстановить, восстановив его индексный дескриптор. Но только до тех пор, пока на место удаленного файла не был записан другой. Именно поэтому если требуется восстановление информации на диске, рекомендуется немедленно отключить ПК и после этого отдельно подключать носитель информации для процедуры восстановления. Так же на данном принципе основано сокрытие информации в Информационной безопасности, когда на носитель информации в 2 или 3 прохода записываются псевдослучайные данные. Для восстановления данных мы можем использовать команду lsdel. Данная команда показывает удаленные файлы.
В принципе на данном debugfs и основаны многие программы для восстановления данных.
На скриншоте хорошо видно, что был удален 1 inode с номером 12 дата и время, другие параметры. Для выхода используем q. Для восcтановления используем undel test.txt, команда, номер индексного дескриптора и имя файла с которым оно восстановится. Убедиться, что файл на месте можно с помощью команды ls.
Утилита debagfs помогает восстанавливать файлы и вообще работать с файловой системой на низком уровне. Конечно восстанавливать по 1 файлу, это очень трудозатратно. Поэтому вот эти низкоуровневые утилиты используют более современные программы.
Еще одна утилита dumpe2fs. Можно вызвать справку по данной утилите man dumpe2fs
Данная команда делает дамп информации, которая хранится на данных томах. Выполним данную команду для /dev/sdc1
Мы получим следующий вывод информации.
Данный вывод был сделан на стандартный вывод – т.е экран. Сделаем вывод в файл, например:
dumpe2fs /dev/sdc1 > /tmp/output.txt
Мы можем просмотреть информацию в выведенную в файл поэкранно с помощью less /tmp/output.txt
В выводе мы сможем увидеть основные опции данной файловой системы.
Переделаем файловую систему, текущую ext4 в ext2. Это можно сделать 3-мя способами с помощью утилит: mkfs, mke2fs, mkfs.ext2. Перед переформатирование необходимо отмонтировать файловую систему. После форматирования и перемонтируем. Опять снимаем дамп и передаем по конвееру на команду grep чтобы посмотреть features. Получаем следующее:
dumpe2fs /dev/sdc1 | grep features
И видим, что файловые системы отличаются, более новая файловая система имеет фишку журналирования has_jounal. Данная опция так же присутствует в ext3. Т.е в данных файловых системах имеются журналы с помощью которых удобно восстанавливать.
Есть интересная утилита tune2fs – настраивать файловую систему.
man tune2fs
Данная утилита, как следует из описания настраивает настраиваемые параметры файловых систем. Например, у нас есть не журналируемая файловая система ext2. Мы даем команду tune2fs –O has_journal /dev/sdc1. Данная утилита добавляет опцию ведения журнала к файловой системе ext2. Или можем наоборот сказать удалить опцию поставив значок ^.