По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
В первой части статей о протоколе Border Gateway Protocol (BGP) мы узнали и разобрали протокол BGP, а затем изучили типы сообщений BGP и состояния соседства. Сегодня, в этой статье, вы узнаете об одном из самых сложных аспектов BGP: как он принимает решение о выборе маршрута. В то время как протоколы маршрутизации, такие как RIP, OSPF и EIGRP, имеют свои собственные метрики, используемые для выбора «лучшего» пути к целевой сети, BGP использует коллекцию атрибутов пути (PAs). Предыдущие статьи цикла про BGP: Основы протокола BGP Видео: Основы BGP за 7 минут BGP- атрибуты пути (Path Attributes) Когда ваш спикер BGP получает BGP префикс, к нему будет прикреплено множество атрибутов пути, и мы знаем, что они будут иметь решающее значение, когда речь заходит о том, чтобы BGP выбрал самый лучший путь к месту назначения. Все атрибуты BGP- маршрута, делятся на четыре основные категории. Well-Known Mandatory Well-Known Discretionary Optional Transitive Optional Non-Transitive Обратите внимание, что две категории начинаются с термина Well-Known. Well-Known означает, что все маршрутизаторы должны распознавать этот атрибут пути. Две другие категории начинаются с термина Optional. Optional означает, что реализация BGP на устройстве вообще не должна распознавать этот атрибут. Тогда у нас есть термины mandatory и discretionary, связанные с термином Well-Known. Mandatory означает, что обновление должно содержать этот атрибут. Если атрибута нет, тогда появится сообщение об ошибке уведомления, и пиринг будет удален. Discretionary, конечно, будет означать, что атрибута не должно быть в обновлении. У необязательных категорий атрибутов есть- транзитивные и нетранзитивные. Если он транзитивен, то устройство должно передать этот атрибут пути своему следующему соседу. Если он не является транзитивным, то может просто игнорировать это значение атрибута. Пример 1 показывает проверку нескольких атрибутов пути для префикса, который был получен маршрутизатором TPA1 от маршрутизатора ATL. Обратите внимание, что мы используем команду show ip bgp для просмотра этой информации, которая хранится в базе данных маршрутизации BGP. В частности, этот вывод показывает атрибуты Next Hop, Metric (MED), LocPrf (Local Preference), Weight, и Path (AS Path). TPA1#show ip bgp BGP table version is 4, local router ID is 10.10.10.1 Status codes: s suppressed, d damped, h history, * valid, > best, i – internal, r RIB-failure, S Stale Origin codes^ I – IGP, e – EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 100.100.100.0/24 10.10.10.2 0 200 i Атрибут Origin Атрибут ORIGIN в BGP-это попытка записать, откуда пришел префикс. Существует три возможности, когда речь заходит о происхождении этого атрибута: IGP, EGP и Incomplete. Как видно из легенды примера 1, коды, используемые Cisco для этих источников, являются i, e, и ?. Для префикса, показанного в примере 1, можно увидеть, что источником является IGP. Это указывает на то, что префикс вошел в эту топологию благодаря сетевой команде внутри конфигурации этого исходного устройства. Далее в этой статье мы рассмотрим сетевую команду во всей ее красе. Термин IGP здесь предполагает, что префикс произошел от записи протокола внутреннего шлюза (Gateway Protocol). Допустим, у нас есть префикс в нашей таблице маршрутизации OSPF, а затем мы используем сетевую команду внутри BGP, чтобы поместить его в экосистему BGP. Конечно, IGP - не единственный источник префиксов, которые могут нести этот атрибут. Например, вы можете создать локальный интерфейс обратной связи на устройстве, а затем использовать сетевую команду для объявления этого локального префикса в BGP. EGP ссылается на ныне устаревший протокол внешнего шлюза (Exterior Gateway Protocol), предшественник BGP. В результате вы не увидите этот исходный код. Incomplete означает, что BGP не уверен в том, как именно префикс был введен в топологию. Наиболее распространенным сценарием здесь является то, что префикс был перераспределен в Border Gateway Protocol из какого-то другого протокола, обычно IGP. Возникает вопрос, почему исходный код имеет такое значение. Ответ заключается в том, что это ключевой фактор, когда BGP использует свой алгоритм для выбора наилучшего пути к месту назначения в сети. Он может разорвать «связи» между несколькими альтернативными путями в сети. Мы также уделяем этому атрибуту большое внимание, потому что это действительно один из хорошо известных, обязательных атрибутов, которые должны существовать в наших обновлениях. Атрибут AS Path AS Path - это well-known mandatory атрибут. Он очень важен для наилучшего поиска пути, а также для предотвращения петель внутри Border Gateway Protocol. Рассматривая нашу топологию, показанную на рисунке 1, рассмотрим префикс, возникший в TPA. Обновление отправляется в TPA1, и TPA не добавляет свой собственный AS 100 в AS Path, так как сосед, которому он отправляет обновление, находится в своем собственном AS в соответствии с пирингом iBGP. Когда TPA1 отправляет обновления на ATL, он добавляет номер 100 в обновления. Следуя этой логике, ATL отправит обновления на ATL2 и не будет добавлять свой собственный номер в качестве AS. Это будет работать до тех пор, пока ATL2 не отправит обновления на какой-то другой AS, предшествующий AS 200. Это означает, что, когда мы рассматриваем образец AS path, как показано в примере 2, крайним правым в пути является AS, который первым создал префикс (100), а крайним левым- AS, который доставил префикс на локальное устройство (342). Пример 2: Пример BGP AS Path Атрибут Next Hop На самом деле нет ничего удивительного в том, что префикс BGP имеет атрибут под названием Next Hop. В конце концов, маршрутизатор должен знать, куда отправлять трафик для этого префикса. Next Hop атрибут удовлетворяет эту потребность. Интересным моментом здесь, однако, является тот факт, что Next Hop в BGP работает не так же, как это происходит в большинстве IGP. Также следует отметить, что правила меняются, когда вы рассматриваете iBGP в сравнении с eBGP. При рассмотрении протокола внутреннего шлюза, когда устройство отправляет обновление своему соседу, значением Next Hop по умолчанию является IP-адрес интерфейса, с которого отправляется обновление. Этот параметр продолжает сбрасываться каждым маршрутизатором по мере прохождения обновления через топологию. Next Hop принимает простую парадигму «hop-by-hop». С помощью BGP, когда у нас есть пиринг eBGP и отправляется префикс, Next Hop действительно будет (по умолчанию) IP-адресом спикера eBGP, отправляющего обновление. Однако IP-адрес этого спикера eBGP будет сохранен в качестве Next Hop, поскольку префикс передается от спикера iBGP к спикеру iBGP. Очень часто мы видим атрибут Next Hop, являющийся IP-адресом, который не является устройством, передавшим нам обновление. Это действительно адрес, который представляет собой соседний AS, который предоставил нам префикс. Таким образом, правильно думать о BGP как о протоколе «AS-to-AS» вместо протокола «hop-to-hop». Это может вызвать определенные проблемы. Основной вывод состоит в том, что вы должны гарантировать, что все ваши спикеры BGP могут достичь значения Next Hop указанного в атрибуте, чтобы путь считался допустимым. Иначе говоря, спикеры BGP будут считать префикс недопустимым, если они не смогут достичь значения Next Hop. К счастью, эту проблему можно обойти. Вы можете взять устройство iBGP и проинструктировать его, установив себя в качестве значения Next Hop всякий раз, когда вам это нужно. Это делается с помощью манипуляции пирингом командой neighbor, как показано в примере 3. ATL (config)# router bgp 200 ATL (config-router)# neighbor 10.10.10.1 next-hop-self Атрибут BGP Weight (веса) Weight (вес) - это очень интересный атрибут BGP, так как он специфичен для Cisco. Хорошая новость заключается в том, что, поскольку Cisco является гигантом в отрасли сетей, то многие другие производители будут поддерживать использование Weight в качестве атрибута. Weight также является одним из самых уникальных атрибутов, поскольку это значение не передается другим маршрутизаторам. Weight - это значение, которое присваивается нашим префиксам как локально значимое значение. Weight - это простое число в диапазоне от 0 до 65535, и чем выше значение веса, тем выше предпочтение этого пути. Когда префикс генерируется локально, он будет иметь вес 32768. В противном случае вес префикса по умолчанию равен 0. Как можно использовать вес? Поначалу это покажется странным, так как он не передается другим спикерам BGP. Однако все просто. Допустим, ваш маршрутизатор получает один и тот же префикс от двух разных автономных систем, с которыми он работает. Если администратор хочет предпочесть один из путей по какой-либо причине, он может манипулировать локальным значением веса на предпочтительном пути и мгновенно влиять на процесс принятия решения о наилучшем пути BGP. BGP Best Path (выбор лучшего пути) Как было сказано ранее, мы знаем, что у IGP есть метрическое значение, которое является ключевым для определения наилучшего пути к месту назначения. В случае с OSPF эта метрика основана на стоимости, которая основана на пропускной способности. У BGP существует множество атрибутов пути, которые может иметь префикс. Все они поддаются алгоритму выбора наилучшего пути BGP. На рисунке 2 показаны шаги (начиная сверху), которые используются в выборе наилучших путей Cisco BGP. Изучая эти критерии выбора пути, вы можете сразу же задаться вопросом, почему он должен быть таким сложным. Помните, когда мы имеем дело с чем-то вроде интернета, мы хотим, чтобы было как можно больше регулировок для политики BGP. Мы хотим иметь возможность контролировать, насколько это возможно, как префиксы используются совместно и предпочтительно в такой большой и сложной сети.
img
В этой статье поговорим о локализации проблем функционирования ESXi/ESX. Неисправности. Что может быть не так? ПО, работающее в гостевой виртуальной машине - медленно реагирует на команды управления; ПО, работающее в гостевой виртуальной машине, периодически прерывают работу; Гостевая виртуальная машина работает медленно или не отвечает на запросы. Проблемы с производительностью могут случаться из-за ограничений центрального процессора (CPU), переполнения памяти или, например, задержкой сети. Если виртуалки работают плохо, скорее всего имеют место траблы с памятью. Устраним? Решение (воркэраунд) Ограничения центрального процессора (проблемы CPU) Чтобы определить, связана ли низкая производительность виртуалки с ограничением центрального процессора, надо: Используйте команду esxtop для того, чтобы определить основные параметры производительности аппаратного сервера виртуалки Проверьте командой load average загрузку. Если среднее значение нагрузки равно 1.00 , то физические ЦП (центральные процессоры) гипервизора ESXi/ESX полностью используются, а среднее значение нагрузки, равное 0.5, значит, что используются наполовину. Логика, думаю, вам понятна. Значение нагрузки, равное 2.00, означает, что система в целом переполнена (бегите в серверную с огнетушителем 👀) Проверьте поле %READY на процент времени на момент, когда виртуальная машина была готова, но не смогла запуститься на физическом ЦП. При нормальных условиях эксплуатации это значение должно находиться в пределах 5%. Если это значение высокое, и виртуальная машина имеет плохую производительность, тогда проверьте ограничение центрального процессора: Убедитесь, что на виртуальной машине не установлен предел ЦП. Убедитесь, что на виртуальной машине не установлен пул ресурсов (Resource Pool). Если среднее значение нагрузки слишком высокое и время ожидания не вызвано ограничением центрального процессора, тогда отрегулируйте нагрузку ЦП на хост. Чтобы настроить нагрузку на хост, выполните следующие шаги: Увеличьте значение физического ограничения ЦП на хост Или уменьшите виртуальное ограничение ЦП, выделенное хосту. Чтобы уменьшить это ограничение, сделайте: Уменьшите общее количество ЦП, выделенных всем виртуальным машинам, работающих на узле ESX Или уменьшите количество виртуальных машин, работающих на хосте (но это весьма грубый способ, как мы считаем) Если Вы используете ESX 3.5, проверьте доступ к IRQ. Переполнение памяти Чтобы определить, связана ли низкая производительность с избыточностью памяти: Используйте команду esxtop для того, чтобы определить основные параметры производительности аппаратного сервера виртуалки. Проверьте параметр MEM в первой строке вывода. Это значение отражает отношение запрошенной памяти к доступной, минус 1. Например: Если виртуальным машинам требуется 4 ГБ ОЗУ, а хост имеет 4 ГБ ОЗУ, то справедливо соотношение 1:1. После вычитания 1 (из 1/1) поле MEM overcommit avg считывает 0. Вывод - избытка нет и не требуется дополнительной оперативной памяти. Если виртуальным машинам требуется 6 ГБ ОЗУ, а хост имеет 4 ГБ ОЗУ, то есть соотношение 1,5:1. После вычитания 1 (из 1,5/1), поле overcommit avg МЭМ считывает 0,5. Объем оперативной памяти превышен на 50%, что означает, что требуется на 50% больше доступной оперативной памяти. Если память перегружается, отрегулируйте нагрузку на хост. Чтобы настроить нагрузку на память, выполните следующие действия: Увеличьте количество физической оперативной памяти на хосте Или уменьшите объем оперативной памяти, выделенной виртуальным машинам. Для уменьшения объема выделенной оперативной памяти: Уменьшите общий объем оперативной памяти, выделяемой всем виртуальным машинам на узле Или уменьшите общее число виртуальных машин на узле. Определите, являются ли виртуальные машины "раздувающимися" или/и заменяемыми. Для обнаружения раздувания или замены: Запустите esxtop Введите m для просмотра памяти Введите f для управления колонками вывода (полями) Выберите букву J в поле Memory Swap Statistics "Статистика раздувания памяти" (MCTL) Посмотрите на значение MCTLSZ. MCTLSZ (MB)отображает объем физической памяти гостя, возвращаемой драйвером баллона (Memory Ballooning). Введите f для управления колонками вывода (полями) Выберите букву для статистики свопов памяти (SWAP STATS) Посмотрите на значение SWCUR. SWCUR (MB) отображает текущее использование обмена. Чтобы устранить эту проблему, убедитесь, что раздувание и/или замена не вызваны неправильно установленным пределом памяти Период ожидания запоминающего устройства Чтобы определить, связана ли низкая производительность с задержкой хранения данных: Определите, связана ли проблема с локальным хранилищем. Если связана, то перенесите виртуальные машины в другое место хранения. Уменьшите количество виртуальных машин на одно логическое устройство. Найдите записи журнала в Windows guests, которые выглядят следующим образом: The device, DeviceScsiPort0, did not respond within the timeout period. Используя esxtop, найдите высокое время задержки DAVG. Определите максимальную пропускную способность ввода-вывода, которую можно получить с помощью команды iometer. Сравните результаты iometer для виртуальной машины с результатами для физической машины, подключенной к тому же хранилищу. Проверьте наличие конфликтного обращения к ресурсу SCSI. Если вы используете ресурсы хранения iSCSI и группу данных jumbo, убедитесь, что все настроено правильно. Если вы используете ресурсы хранения iSCSI и передачу по нескольким трактам с использованием программного инициатора iSCSI, убедитесь, что все настроено правильно. При выявлении проблемы, связанной с хранением: Убедитесь, что аппаратный массив устройства и платы HBA сертифицированы для ESX/ESXi. Убедитесь, что BIOS физического сервера обновлена. Убедитесь, что встроенное ПО вашего HBA-адаптера обновлено. Убедитесь, что ESX может распознать правильный режим и политику пути для типа массива хранения SATP и выбора пути PSP. Задержка сети На производительность сети может сильно влиять производительность ЦП. Исключите проблему производительности ЦП перед исследованием сетевой задержки. Чтобы определить, вызвана ли низкая производительность задержкой сети, выполните следующие действия: Проверьте максимальную пропускную способность виртуальной машины с помощью инструмента Iperf. При использовании Iperf измените размер окон TCP на 64 K. Производительность также зависит от этого значения. Чтобы изменить размер окон TCP: На стороне сервера введите следующую команду: iperf –s На стороне клиента введите следующую команду: iperf.exe -c sqlsed -P 1 -i 1 -p 5001 -w 64K -f m -t 10 900M Запустите Iperf с компьютера вне хоста ESXi/ESX. Сравните результаты с ожидаемыми, в зависимости от физической среды. Выполните команду Iperf с другого компьютера вне хоста ESXi/ESX в той же VLAN на том же физическом коммутаторе. Если производительность хорошая, и проблему можно воспроизвести только на машине в другом географическом месте, то проблема связана с вашей сетевой средой. Выполните команду Iperf между двумя виртуальными машинами на одном сервере ESX/portgroup/vswitch. Если результат хороший, можно исключить проблему с ЦП, памятью или хранилищем. Если вы определяете параметры, которые ограничивают производительность системы в сети: Если вы используете ресурсы хранения iSCSI и кадры jumbo, убедитесь, что все настроено правильно. Если вы используете Network I/O Control,то убедитесь, что общие ресурсы и ограничения правильно настроены для вашего трафика. Проверьте правильность настройки формирования траффика.
img
Когда базы данных Oracle не работают, целесообразно проверить подключения к ним. Периодически приходится проверять, работает ли база данных Oracle. Иногда процесс, запущенный на одном сервере, извлекает данные из базы данных на другом сервере, и, если процесс завершается неудачей, тестирование соединения с базой данных является хорошей отправной точкой для определения того, что пошло не так. Проверка локальной базы данных Если база данных находится в локальной системе, сперва проверяем состояние процесса и должны увидеть результат, подобный показанному на скриншоте ниже. Эти выходные данные говорят нам, что процессы Oracle запущены, включая tnslsnr, часто называемый «прослушивателем» и критически важный для подключения к локальной базе данных. Также можно проверить вывод команды netstat, чтобы увидеть, порт, который «опрашивает» Oracle и использует по умолчанию. Это порт, который должен был открыть «прослушиватель». Использование tnsping Другая, потенциально более полезная команда - это tnsping, которая использует информацию из файла БД Oracle tnsnames.ora для проверки возможности подключения. Если, например, набрать команду tnsping ORCL, команда будет искать базу данных с именем службы ORCL, отправит запрос типа ping на настроенный порт и сообщит об ответе. Успешный ответ от tnsping будет выглядеть примерно так: Обратите внимание на ответ «ОК» в последней строке. Также получен отчет о том, сколько времени потребовалось на ответ. Одиннадцать секунд - быстрый ответ. Если проверялась удаленная система, то потребовалось бы в десять или более раз больше времени, чтобы получить ответ. Если Oracle прослушивает порт, отличный от 1521, команда tnsping все равно будет работать, предполагая, что файл tnsnames.ora содержит правильную информацию. Запись tnsnames.ora для одной базы данных будет выглядеть примерно так: Обратите внимание, как имя службы (ORCL), которое использовалось в примере команды tnsping, и порт, на который отвечает «прослушиватель» Oracle (1521), настроены в этом дескрипторе базы данных. Использование sqlplus Другая команда, которую любят использовать администраторы БД для проверки связи с базой данных Oracle - это sqlplus. С помощью sqlplus (установленного вместе с Oracle) можно проверить, отвечает ли Oracle, а также и запустить несколько команд sqlplus, чтобы убедиться, что таблицы или их содержимое соответствуют тому, что мы ожидаем увидеть. Команда sqlplus имеет следующую форму для подключения к базе данных Oracle: sqlplus username/password@SID SID в этом описании может быть SID или SERVICE_NAME, взаимозаменяемыми в некоторых версиях Oracle. Например, можно ввести: % sqlplus admin/f0xtrawt@ORCL Эта команда определяет имя пользователя, пароль и SERVICE_NAME/SID в одной команде. После подключения можно ввести пару команд sql, чтобы убедиться, что база данных работает правильно. Можно подсчитать количество пользовательских таблиц с помощью такой команды: SQL> select count(*) from user_tables; COUNT(*) ---------- 45 Создание скрипта Поскольку я не так часто пытаюсь устранить неполадки в базах данных Oracle, я предпочитаю сохранять команды для подключения к конкретной базе данных в виде простого скрипта. Я мог бы назвать скрипт для подключения к локальной базе данных connect2local и аналогичный сценарий для подключения к базе данных на удаленном сервере connect2rem или connect2mars (если удаленная система была названа mars). Чтобы облегчить мне использование БД Oracle, я сохраню переменные, которые хочу использовать, в профиле и буду использовать их по мере необходимости: Мною написанный скрипт будет выглядеть так: Когда я набираю connect2local, я ожидаю увидеть в ответ OK и возможность остаться в приглашении SQL>, из которого я могу выдавать запросы или набрать quit для выхода. Быстрые тесты, позволяющие определить, реагирует ли база данных Oracle, имеют большое значение для устранения проблем с подключением.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59