Как представляется многим, управление пропускной способностью не требует каких-либо серьезных умственных усилий. Либо вы стремитесь сэкономить этот драгоценный ресурс, насколько это возможно, либо (если вы принадлежите к тем немногим счастливчикам, у кого он имеется в достатке) разделяете и распределяете его таким образом, чтобы даже маленький кусочек не пропал даром.

Однако на практике этот вопрос оказывается куда сложнее. Все возрастающее разнообразие приложений и изменение сетевой инфраструктуры в значительной степени усложняют задачу управления пропускной способностью. Имеющиеся и появляющиеся приложения, такие, как VPN, настольные видеоконференции и голос по IP, требуют своей доли ресурсов, а смешение низкоскоростных и высокоскоростных сетевых сегментов часто порождает проблемы с точки зрения общей производительности.

Другим определяющим фактором роста потребности в эффективном управлении пропускной способностью является спрос на жесткие соглашения об уровне сервиса с операторами и провайдерами услуг со стороны корпоративных заказчиков. Возможность контролировать потоки трафика через сеть провайдера услуг необходима заказчику для сохранения уверенности в выполнении провайдером услуг его части соглашения. Конечно, и провайдеру услуг требуются какие-то механизмы для контроля за соблюдением заказчиком его части соглашения.

Естественно, мы не можем обойти вниманием вопрос отдачи. Хотя продукты и решения по управлению пропускной способностью обходятся недешево, они стоят потраченных на них денег. Обеспечение наибольшего приоритета приносящим доход приложениям, таким, как электронная коммерция, превращается в первоочередную задачу с увеличением числа конкурирующих за пропускную способность приложений.

Иными словами, если у вас есть пропускная способность, то за ней необходим контроль. Но в какой степени? И каким образом? Например, в какой-то момент увеличение пропускной способности для ликвидации перегрузок в сети может оказаться нецелесообразным — все зависит от причины и местонахождения узкого места. В частности, такое решение возможно в локальной сети, но оно непрактично в глобальной сети, где пропускная способность стоит дороже.

Какой же подход взять на вооружение, когда дело касается вашей сети? Следует ли инвестировать средства в сложные комплексные решения или рискнуть ограничиться более консервативным подходом, хотя он может и не дать желаемого результата?

Первый шаг на пути к ответу на эти вопросы состоит в знакомстве с различными категориями и технологиями, определяющими сегодня картину управления пропускной способностью.

Традиционно управление пропускной способностью служило в качестве обобщающего термина для описания распределения ширины полосы глобальных сетей или пропускной способности локальных сетей в соответствии с требованиями разнообразных приложений. Подмножеством управления пропускной способностью является формирование трафика — процесс распределения трафика по приоритетам для предоставления пропускной способности на гарантированном уровне. Управление с помощью правил, еще одна подкатегория, обычно относится к интегральной реализации приоритетов трафика на базе правил. Этот подход используется для обеспечения сквозного качества обслуживания и функций защиты.

Как бы они ни были реализованы — программно, аппаратно или в виде комбинации данных подходов, продукты для управления пропускной способностью принадлежат к одной из упомянутых категорий. Это могут быть автономные, а также встроенные в такие устройства, как коммутаторы и маршрутизаторы, серверы правил. Это могут быть продукты для формирования трафика, причем некоторые из них способны выполнять распределение нагрузки, перенаправление кэша и функции учета.

При управлении с помощью правил управление пропускной способностью тесно интегрируется с самыми разными сетевыми технологиями. Например, в схеме, где применяются серверы DNS, после регистрации пользователей сервер DHCP выполняет свою обычную функцию выделения IP-адресов этим пользователям. Затем сервер правил назначает множество сервисных классов по умолчанию. (Более подробное исследование данной темы можно найти в статье «На пути к управлению в соответствии с заданными правилами» в мартовском номере LAN за 1999 год.)

Другая связка, обещающая стать еще крепче, — это интеграция со службой каталога. Каталог может служить хранилищем для элементов, непосредственно относящихся к управлению пропускной способностью, в том числе информации о приоритетах. Некоторые продукты для хранения информации и привязки ее к схемам распределения пропускной способности, в зависимости от таких переменных, как права защиты, местонахождение и группа пользователей, используют упрощенный протокол доступа к каталогу (Lightweight Directory Access Protocol, LDAP). Например, Policy Manager компании Allot и WideSpan Service Controller для провайдеров Internet компании Bridgewater Systems поддерживают LDAP.

Управление пропускной способностью продолжает использоваться в сочетании с функциями защиты. Access Point от Xedia и WiseWan от NetReality имеют встроенные брандмауэры Firewall/QoS Manager и обновление WiseWan Firewall Management, соответственно. Комплект VPN-1/Firewall-1 компании Check Point Software Technologies позволяет задать приоритет трафика до его шифрования.

Другая важная тенденция управления пропускной способностью состоит в росте популярности продуктов для распределения нагрузки. Данная функциональность может реализовываться разными способами, в том числе с помощью программного обеспечения распределения нагрузки, специализированных устройств и коммутаторов распределения нагрузки. Эти решения позволяют равномерно распределить трафик между серверами в крупных парках серверов, какие встречаются, например, в центрах обработки данных Web.

Многие из упомянутых продуктов поддерживают такие функции, как перенаправление кэша и кластеризация серверов. Коммутатор распределения нагрузки между серверами ACEdirector от Alteon и коммутатор ServerIron от Foundry Networks — вот всего лишь два представителя этой чрезвычайно населенной категории.

Выше мы перечислили только некоторые тенденции, гарантирующие пристальное внимание к управлению пропускной способностью как с технической, так и с рыночной точки зрения.

Основная задача управления пропускной способностью — это регулирование трафика в целях наиболее эффективного использования пропускной способности. Контроль скорости и организация очередей составляют два основных средства контроля трафика. Сравнительные характеристики и недостатки этих технологий широко дискутировались, хотя некоторые из имеющихся продуктов сочетают в себе оба подхода.

Контроль скорости применяется для выравнивания обычно чрезвычайно неравномерного трафика по соединениям TCP и позволяет осуществлять контроль трафика в обоих направлениях. Цель контроля скорости состоит в снижении скорости передачи в периоды перегрузки.

При контроле скорости потоки идентифицируются в соответствии с такими переменными, как адрес отправителя, адрес получателя и номер порта. На основании этой информации механизмы контроля скорости позволяют соответствующим образом настроить такие параметры, как окно TCP, от величины которого зависит, какой объем данных система может передать в данный момент времени.

Принимающее устройство задает размер окна TCP для сообщения отправителю о том, сколько свободного места имеется в его буфере. Эта информация включается в каждый пакет с подтверждением TCP. Контроль скорости позволяет смягчить проблему переполнения буферов из-за избыточных повторных передач.

Задание надлежащего размера окна представляет собой непростую задачу. Если окно TCP чересчур мало, то это ведет к увеличению задержки. Если окно чересчур велико, то пакеты могут быть потеряны при передаче, и их придется передавать повторно, что чревато переполнением буфера.

При определении размера окна необходимо учитывать задержку на передачу пакетов в прямом и обратном направлениях, а также пропускную способность из конца в конец. От этих факторов зависит, какой объем данных может находиться в пути в любой конкретный момент времени. Это подчеркивает важность точной оценки всех возможных переменных при определении надлежащего размера окна.

Задача определения надлежащего размера окна оказывается особенно сложной в среде с сильно меняющейся во времени картиной трафика. Кроме того, некоторым приложениям могут потребоваться окна большего или меньшего размера, чем другим, — не лучшая диспозиция с учетом постоянного роста числа и многообразия приложений в современных сетях. Ключом к успешной реализации контроля скорости является частый мониторинг потоков трафика и возможность быстро и точно регулировать размеры окна TCP для эффективного манипулирования потоками трафика.

В случае применения очередей потоки распределяются между различными очередями в зависимости от их приоритета. Очереди могут быть организованы в соответствии с одной из нескольких схем, в том числе как очереди по приоритетам, «честная взвешенная очередь» (Weighted Fair Queuing, WFQ) и очереди в соответствии с классами (Class-Based Queuing, CBQ).

Организация очередей по приоритетам предполагает создание отдельных исходящих очередей для разных классов трафика на одном и том же исходящем порту. Высокоприоритетный трафик идентифицируется с помощью таких механизмов, как поле типа сервиса (Type of Service, ToS) в заголовке IPv4. (Это однобайтное поле первоначально использовалось в качестве механизма идентификации приоритета обработки пакета.) Низкоприоритетный трафик не будет передаваться, пока не опустеют все очереди с более высоким приоритетом.

Для предотвращения таких проблем, как частые тайм-ауты и повторные передачи, схема организации очередей по приоритетам была усовершенствована, что привело к появлению схемы честной очереди. В соответствии с этой схемой всем очередям гарантируется определенная доля пропускной способности. В случае WFQ, дальнейшего усовершенствования этой схемы, трафик распределяется по классам приоритетов, причем каждому приоритету соответствуют потоки с высокой или низкой пропускной способностью. Потоки этих классов чередуются, что ведет к более равномерной передаче данных.

В случае CBQ трафик классифицируется в зависимости от IP-адреса, протокола, типа приложения, URL и других параметров. Каждый класс трафика затем формируется в соответствии с определенным уровнем пропускной способности. Если какому-нибудь классу трафика требуется дополнительная пропускная способность, то он может «позаимствовать» ее у другого класса, не использующего всю выделенную ему в данный момент времени пропускную способность.

Но, в отличие от контроля скорости, механизмы организации очередей не являются двунаправленными. Кроме того, они способны привести к тайм-аутам при переполнении очередей. Чтобы обойти это затруднение, размер очереди можно увеличить, но такой подход имеет свои недостатки. Например, если размер очереди окажется чрезмерно большим, то различия в задержке в случае пустой и полной очередей могут привести к сильной вариации задержки.

PacketShaper от Packeteer является, наверно, наиболее популярной реализацией механизмов контроля скорости, в то время как Access Point от Xedia известен своей поддержкой CBQ. (Более подробные сведения о продуктах этой категории можно найти в статье «Оптимизация распределения пропускной способности» в февральском номере LAN за 1999 год.) Однако растущее число продуктов, где используются обе технологии, указывает, что различия между двумя подходами постепенно стираются.

При выборе наиболее подходящего для вашей сети продукта вам придется учитывать такие факторы, как объем пакетного трафика в сети, соотношение чувствительного и нечувствительного ко времени трафика и возможное изменение объема трафика в будущем.

Главным препятствием на пути всеобъемлющего управления пропускной способностью является отсутствие совместимости. Пока не будет достигнут определенный уровень стандартизации, возможности пользователя по реализации исчерпывающего решения с использованием продуктов различных производителей будут носить весьма ограниченный характер. Однако все не так безнадежно: IETF занимается несколькими находящимися на разных стадиях готовности стандартами, протоколами и моделями правил.

Весьма обнадеживающе выглядит разработка стандарта на дифференцированные услуги (Differentiated Services, DiffServ). В случае DiffServ IP-пакеты могут быть дифференцированы с помощью бита ToS в заголовке, и, таким образом, DiffServ-совместимые маршрутизаторы и коммутаторы будут знать, как классифицировать пакет в соответствии с заранее заданными правилами. Значение этого поля в заголовке определяет, как пакет будет обрабатываться на каждом транзитном узле сети. Основное преимущество подхода DiffServ в его масштабируемости, в том числе на крупные сети, поскольку он исключает необходимость учета состояния потока и индивидуальной обработки каждого из них.

Предназначенный для использования с DiffServ протокол RSVP+ позволяет приложению идентифицировать себя в сети, чтобы оно могло получить соответствующее его приоритету обслуживание. Это расширение RSVP предполагает некоторое видоизменение стандартной процедуры обработки сообщений RSVP на маршрутизаторах, в частности контроль допуска к агрегативным классам DiffServ и поддержку агрегированного и туннелируемого RSVP.

Общий открытый сервис правил (Common Open Policy Service, COPS) представляет собой протокол по типу запрос-ответ для обмена информацией о правилах между сервером правил и его клиентами. Например, пусть коммутатор посылает сообщение COPS серверу правил. Это сообщение будет содержать специфическую информацию о клиенте, а также действия, которые он просит выполнить целевое устройство. Исходный запрос идентифицирует клиента и указывает на событие, наступление которого инициировало подачу запроса; ответ на него будет содержать решение, принятое сервером правил. Это позволяет реализовать наиболее эффективное распределение ресурсов.

Протокол DIAMETER обеспечивает взаимодействие между клиентами в целях идентификации, авторизации и учета различных сервисов (Authentication, Authorization, and Accounting, AAA). Например, сервер правил может по собственной инициативе послать клиентам сообщения, а это означает возможность внесения в правила изменений с немедленным сообщением о них клиенту(-ам). Легшая в основу DIAMETER концепция состоит в создании базового протокола с возможностью его расширения для предоставления сервисов AAA при появлении новых технологий доступа. Отчасти протокол создавался для преодоления некоторых ограничений RADIUS.

В случае многопротокольной коммутации с заменой меток (Multiprotocol Label Switching, MPLS) такие устройства, как коммутаторы и маршрутизаторы, могут присвоить метки каждой записи в своих таблицах маршрутизации и передать информацию об этих метках другим устройствам. С помощью метки система может идентифицировать следующий транзитный узел на пути передачи пакета без просмотра адреса. Такой подход позволяет использовать явную маршрутизацию — более эффективную стратегию, чем общий метод выбора кратчайшего пути, тем более что кратчайший путь может оказаться чересчур перегружен. В свою очередь, этот оптимизированный процесс маршрутизации позволяет более эффективно использовать пропускную способность (см. статью «MPLS: лиха беда начало» в этом номере LAN).

IETF работает над определением общей схемы реализации сетевых технологий на базе правил, включая правила обеспечения QoS. Так, она сформировала рабочую группу по протоколу распределения ресурсов (Resource Allocation Protocol, RAP) для разработки масштабируемой модели контроля правил для RSVP и интегрированных услуг. Предполагаемая общая схема правил предусматривает точки принятия решений (Policy Decision Point, PDP) и точки реализации решений (Policy Enforcement Point, PEP). PDP принимает решения на основании правил, которые она получает из таких источников, как хранилище правил и серверы идентификации. Как следует из ее имени, PEP реализует определенные PDP правила. PEP содержит элемент, называемый локальной точкой принятия решений (Local PDP, LPDP), с помощью которого некоторые решения могут приниматься непосредственно на PEP.

Общая схема содержит также рекомендации относительно таких компонентов, как информационная база правил (Policy Information Base, PIB), базовая схема правил, архитектура правил, функции правил, определения правил и механизмы хранения и извлечения правил.

Другим элементом этой модели является язык определения общей схемы правил (Policy Framework Definition Language, PFDL), определяющий независимый метод кодирования описаний правил переносимым образом. Основное достоинство PFDL состоит в том, что с его помощью разнородные устройства с поддержкой правил могут взаимодействовать друг с другом и таким образом реализовать общую схему правил.

При всей ограниченности их поддержки, перечисленные стандарты и протоколы прокладывают путь к достижению такой высокой цели, как обеспечение сквозного QoS. Дополнительные подробности о реализации этих протоколов можно почерпнуть во врезке «Демонстрация поддержки».

Беглый просмотр статей в отраслевой прессе мог привести вас к выводу, что дорогостоящее, исчерпывающее, всеохватывающее решение по управлению пропускной способностью является абсолютно необходимым для вашей сети прямо сейчас. Однако все же стоит копнуть поглубже и попытаться оценить пригодность конкретной реализации управления пропускной способностью для вашей сети.

Важно определить, где необходимо реализовать управление пропускной способностью в первую очередь. Должны ли механизмы управления пропускной способностью быть реализованы в локальной сети, глобальной сети или на интерфейсе между ними? Ответ на этот вопрос зависит от нескольких факторов, в том числе от того, где возникают перегрузки. Обычно продукты формирования трафика реализуются на интерфейсе между локальной и глобальной сетями, но они могут располагаться также внутри локальной сети на соединении с маршрутизатором, в самом маршрутизаторе или целиком в глобальной сети (например, между маршрутизатором и коммутатором в общедоступной сети frame relay).

При таком сценарии необходимая степень контроля за пропускной способностью/трафиком зависит от используемых сервисов. В случае ориентированных на соединение общедоступных информационных сервисов, таких, как ATM или frame relay, корпоративные заказчики обычно обязуются не превышать определенного уровня потребления пропускной способности за короткий период времени (например, для ограничения пакетного трафика). Аналогичное соглашение заключается и в отношении среднего потребления пропускной способности за длительный период времени. Эти уровни называются пиковой (максимальной) и средней пропускной способностью, соответственно. Если потребление пропускной способности превосходит оговоренную величину, то провайдер услуг получает основания для удаления пакетов. В этом случае формирование трафика может применяться для удержания трафика в определенных контрактом границах.

«Если провайдер услуг продает «голые» биты — как в случае сервисов T-1 и Т-3 с постоянной скоростью передачи битов, то в области управления пропускной способностью вы можете делать все что угодно, покуда то же самое делается на другом конце канала, — говорит Том Нолле, президент CIMI. — Но если провайдер предоставляет вам интеллектуальную услугу, то как пользователю вам придется придерживаться требований этой услуги в отношении любого трафика, который вы намереваетесь передавать с ее помощью».

«Если провайдер услуг осуществляет пристальный мониторинг вашего трафика, то вам потребуется реализовать механизмы формирования трафика, — добавляет Нолле. — Если ваше устройство доступа позволяет организовать очереди для каждого виртуального канала, а ваше приложение более чувствительно к потерям пакетов, чем к их задержке, то очередь лучше сделать относительно небольшой. С другой стороны, если ваш провайдер услуг не осуществляет жесткого регулирования вашего трафика, а ваше приложение более чувствительно к задержке, чем к потерям пакетов, то наиболее эффективной стратегией будет полный отказ от очереди».

Другое дело — сеть IP без установления соединения. Задача контроля трафика в Internet стала притчей во языцех, именно из-за сложности ее решения обеспечение сквозного качества услуг до сих пор остается отдаленной целью. В случае сети IP решение о реализации управления пропускной способностью на границе сети должно опираться на способность сети обеспечить приемлемые характеристики передачи при взаимодействии со всеми адресатами, обращение к которым может осуществляться через это соединение.

Если сеть обладает такого рода стабильностью, а провайдер услуг предлагает гарантии в соответствии с обеспечиваемым уровнем стабильности, то заказчик может воспользоваться CBQ для того, чтобы его соединение не дестабилизировало работу сети. Но, как предостерегает Нолле, «если услуга не отличается значительным запасом стабильности, то реализация CBQ вряд ли принесет вам заметную выгоду». (Подробнее о потенциальных опасностях можно узнать из врезки «Управление пропускной способностью: задачка для дураков?».)

Чтобы сделать прогноз относительно перспектив управления пропускной способностью, нам придется рассмотреть разработки, способные повлиять на распространение и использование технологии. Если все более жесткие требования, предъявляемые к вашей сети, ведут к нехватке пропускной способности, то никакое управление в мире не позволит повысить ее производительность. В таком случае формирование трафика позволяет частично выйти из положения, но и оно не в состоянии заменить недостающую пропускную способность.

Такие разработки, как мультиплексирование с разделением по длине волны (Wave Division Multiplexing, WDM), с помощью которых пропускная способность оптического волокна может быть значительно увеличена, должны позволить некоторым организациям обойти многие из могущих возникнуть в будущем проблем управления пропускной способностью. Но, несмотря на снижение цен, технология WDM остается весьма дорогой в реализации. Конечно, если тенденция снижения цен продолжится, то приобретение дополнительной емкости станет более привлекательным вариантом, особенно по сравнению с некоторыми наиболее дорогостоящими схемами управления пропускной способностью.

Как бы все ни обернулось, потребность в эффективном управлении пропускной способностью не исчезнет. Вся хитрость — в правильном определении своих требований, чтобы вы могли предоставить требуемый уровень сервиса по сети без приобретения продуктов или технологий, отдача от применения которых может оказаться недостаточной.

С общей точки зрения, управление пропускной способностью является ключевым механизмом для достижения сквозного QoS. Несмотря на то что эта цель остается пока недостижимой, потребность в обеспечении сквозного качества обслуживания служит стимулом для продолжения усилий по стандартизации и для появления разработок в области технологий управления пропускной способностью.

Элизабет Кларк — исполнительный редактор Network Magazine. С ней можно связаться по адресу: eclark@mfi.com.

Несколько протоколов, предложенных IETF, должны оказать значительное влияние на будущее управления пропускной способностью и темпы распространения соответствующих технологий.

Протокол Differentiated Services (DiffServ), в котором трафик распределяется по приоритетам в соответствии с отметками в заголовках пакетов, поддерживается рядом производителей продуктов управления пропускной способностью. Среди них NetReality с системой управления пропускной способностью WiseWan 3.0; Xedia с Access Point и Orchestream с Enterprise Edition 2.0 и Orchestream/Provider. Последние два продукта позволяют задавать правила QoS для предприятий и провайдеров услуг, соответственно.

Программное обеспечение маршрутизации BayRS компании Nortel Networks поддерживает и DiffServ, и Common Open Policy Service (COPS). COPS определяет взаимодействие между серверами правил и другими устройствами, такими, как их клиенты.

Multiprotocol Label Switching (MPLS) использует метки для прокладывания наиболее эффективного пути между устройствами. Он реализован в системах для операторов Versalar, Passport и Optera Packet Solution компании Nortel. По информации из компании, поддержку COPS планируется добавить в будущем. M40 Internet Backbone Router от Juniper Networks также поддерживает этот протокол, как и программное обеспечение маршрутизации IOS компании Cisco Systems.

Помимо поддержки DiffServ компания Xedia со временем планирует реализовать и COPS, и MPLS.

SAP реализовала RSVP+ в своем пакете управления информацией R/3. Протокол, с помощью которого приложение может идентифицировать себя в сети, позволит, например, предоставить приложению SAP R/3 Financials приоритет над заданиями на печать SAP.

Несмотря на то что описания этих разработок звучат многообещающе, читателю следует помнить, что число внедренных систем, поддерживающих названные протоколы, мало по сравнению с инсталлированной базой систем, поддерживающих традиционные протоколы. Что ж, нам остается только подождать и посмотреть, какие из новых протоколов выживут, какие будут поглощены другими протоколами, а какие попросту исчезнут.

Управление пропускной способностью чем-то напоминает борьбу за мир: никто не будет возражать против того, что это нужное дело, но при более внимательном рассмотрении оно представляется совершенно безнадежным.

Сетевой трафик и пропускную способность требуется как-то контролировать, и имеющиеся продукты управления пропускной способностью и формирования трафика могут в этом здорово помочь, в том числе они позволяют сэкономить время и деньги, более эффективно использовать сетевые ресурсы и утихомирить вечно недовольных пользователей.

Управление пропускной способностью далеко не всегда оказывается способно сделать все то, за что его так превозносят. Взять, например, формирование трафика. Если вы используете сеть без установления соединения, но у вас нет соглашения об уровне сервиса с вашим провайдером, то, скорее всего, формирование трафика окажется излишним.

По словам Тома Нолле, президента CIMI, один из принципов, из которых следует исходить, принимая решение о реализации формирования трафика в такой ситуации, состоит в определении изменения характеристик сети при обычных условиях, в отсутствии управления пропускной способностью. Иначе вы можете потратить уйму времени и денег на решение, благодаря реализации которого подаваемые в сеть потоки будут хорошо сформированы, но в сети будут подвергаться серьезным искажениям.

Другим примером может служить программное обеспечение для мониторинга трафика: его использование чревато неприятностями иного рода. Периодически возникающие во многих корпоративных сетях незначительные проблемы могут остаться незамеченными конечными пользователями и не иметь серьезных последствий. В этом случае, как указывает Билл Фланаган, директор программы в NetReference, программное обеспечение, детализирующее незначительные проблемы в вашей сети, может принести больше вреда, чем пользы.

Часто администраторы сетей, думающие, что такие инструменты облегчат их работу, сталкиваются с противоположными результатами. «Если вы каждый час получаете отчет, где говорится «это следует исправить», то кто-нибудь может взять отчет и спросить, почему вы не устранили эту проблему», — говорит Фланаган. Если решение проблемы будет стоить значительных времени, денег и сил, тогда как она оказывает незначительное — или совсем никакого — влияние на сеть, то тогда лучше вообще не приобретать программное обеспечение для мониторинга трафика.

Наконец, нельзя забывать о вопросе обслуживания. С изменением природы и объема сетевого трафика программное обеспечение для мониторинга трафика потребуется соответствующим образом настраивать. В противном случае оно может выдавать неверные результаты. Так что, если ваша компания собирается приобретать такие системы, то вам необходимо учитывать, что придется тратить время, усилия и деньги на приведение этого инструментария в соответствии с потребностями сети.

Вывод следующий: проведите внимательный анализ, прежде чем слепо следовать общему увлечению управлением пропускной способностью. Иначе вы можете уклониться от намеченной цели.