...

суббота, 17 февраля 2018 г.

Тренинг FastTrack. «Сетевые основы». «Понимание архитектуры Cisco». Эдди Мартин. Декабрь, 2012

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

Мы продолжаем цикл из 18 статей на основе его лекций:

Тренинг FastTrack. «Сетевые основы». «Понимание модели OSI». Часть первая. Эдди Мартин. Декабрь, 2012

Тренинг FastTrack. «Сетевые основы». «Понимание модели OSI». Часть вторая. Эдди Мартин. Декабрь, 2012

Тренинг FastTrack. «Сетевые основы». «Понимание архитектуры Cisco». Эдди Мартин. Декабрь, 2012

И вот третья из них.

Тренинг FastTrack. «Сетевые основы». «Понимание архитектуры Cisco». Эдди Мартин. Декабрь, 2012


Переходим к следующему разделу нашей беседы – архитектуре компании Cisco. Мы затронем этот вопрос дважды, в начале наших встреч и в самом конце.

Итак, для чего нужна архитектура и какое значение она имеет для клиента?

Архитектура — очень важное понятие для Cisco. В каком случае архитектура становится важной для клиента? Она важна, если она эффективна. Если она помогает взаимодействовать с приложениями. Но о чём думают клиенты, когда слышат слово архитектура? Они представляют себе стратегию или что-то вроде дорожной карты. Для них слово архитектура звучит дорого. Все мы слышали о клиентах ABC. А каких клиентов мы называем клиентами ABC, или «первоклашками», теми, кто не продвинулись дальше изучения азбуки? Это те клиенты, которые не выбрали Cisco. И мы должны их приманить.

Я сам из Северной Каролины и у нас в штате очень много баскетбольных команд, сосредоточенных в небольшом регионе. Я любил пошутить, что ABC — это Anything But North Carolina, кто угодно, но не Северная Каролина. Потому что в университете Северной Каролины есть лучшая баскетбольная команда, и в Кентукки есть лучшая, и так далее. Также происходит и в сфере информационных технологий – существует значительный слой клиентов «начального уровня», не интересующихся сложными вопросами.

Архитектура становится важной, если мы говорим о долгосрочных стратегиях. Как Вы думаете, IT сфера думает о долгосрочных перспективах? Сейчас я покажу Вам кое-что очень умное, чему меня научил один специалист по продажам. Он сказал, что в каждой организации есть иерархия. Внизу находятся исполнители, в том числе и IT специалисты, и я тоже был среди них. Эти люди не заглядывают далеко в будущее. Они думают: «Боже, уже пятница, почти выходные»! Или: «Уже четверг, я перемахнул за середину недели»! Они не думают о далёких перспективах. Они работают от проекта к проекту и живут лишь сегодняшним днём.

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

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

Именно на этом уровне находится специалист, который выполняет роль архитектора в организации и знает имена руководителей и прочее.

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

О чём же думают все эти люди на верхушке? Какими словами мы их опишем? Чего они хотят?

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

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

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

А теперь поговорим об архитектуре информационных технологий, о трёх основных типах архитектуры, хотя в Cisco есть еще парочка других. Начнём с первого типа — безграничная сетевая архитектура. Что это такое? Безграничная сеть — это что-то новое. Это полностью революционное решение для IT-сферы.

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

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

Второй тип архитектуры — это архитектура сотрудничества, групповая архитектура. В Cisco начали это в далёкие 1997-е годы. Тогда мы не называли это групповой архитектурой, была только идея. Она берёт своё начало c IP-телефонии, которая привела к унифицированному сотрудничеству в области коммуникаций. Всего было три ступени на пути к такому сотрудничеству. Опять же, мы начали это ещё в средине 1990-х в виде видения, ещё не было готовых продуктов, которые могли бы это обеспечить. Мы имели много приобретений тогда, включая Celsius, множество возможностей маршрутизации и это связало нас с мессенджерами коммуникации, видео-решениями, всем, что обеспечивает людям возможность общаться между собой. Из всех типов архитектуры я считаю этот самым важным, так как он даёт нам общение. Я могу быть немного пристрастным, и я буду. Разве Ваши клиенты знают, какие свитчи или роутеры Вы используете в архитектуре и какие там изменения? Нет, и это распространённая шутка. Но мы можем изменить способ общения и таким образом поменять способ ведения бизнеса каждого в организации.

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

Если спросить об этом менеджера, он скажет, что сейчас клиент может поделиться своим мнением в сети, и оно распространиться со скоростью лесного пожара. Но это ещё не всё. Моя дочка Эмили не захочет сидеть на уроках и учиться таким образом. Она хочет встречаться с людьми, общаться в группе. Она будет использовать интерфейс Фейсбука, чтобы иметь доступ к информации. Это и есть социальный аспект архитектуры. Очень много людей моего возраста и старше скоро уйдёт из этой индустрии, вместе с теми знаниями, которые у нас есть. Как Эмили получит их? Кто их получит? Это очень инновационный подход, о котором сейчас думают руководители любых уровней. Нам нужно думать о том, как современная молодёжь хочет получать информацию, в каком виде Эмили предпочитает получать информацию.

Волнует ли это IT-специалистов? Нет, не волнует. Это должно беспокоить продавцов! И Вы обязаны учитывать социальный аспект пользования сетями, потому что это важно для клиента. Об этом постоянно думают те, кто находится наверху пирамиды, кто хочет, чтобы их бизнес существовал ещё много лет.

Последний, третий тип архитектуры – это виртуализация центров обработки данных.

Сейчас наша фирма Cisco продаёт серверы и свитчи Nexus. Мы даём клиентам возможность взять 16 центров обработки данных и сделать так, чтобы они выглядели как один. Мы потратили на это очень много времени в последние несколько лет. Потому, что в последние 15 лет мы поступали глупо и теперь исправляем свои ошибки. Мы наконец нашли технологии, работающие для дата-центров. Это был виртуальный сервер со всеми этими многоядерными процессорами. В Cisco вложили в это очень много сил и денег. Но мы поговорим об этом позже подробнее. Но я снова замечу и задам Вам вопрос. Знает ли средний пользователь, системный администратор, кто-либо, кто занимается вводом данных, или наши клиенты, работают ли они на виртуальном сервере или нет? Нет, в большинстве они этого не знают. Всё это на себе тащит и выполняет групповая архитектура.

Изначально расстановка сил была 6 к 1. Когда мы начали продавать IP-телефонию, на каждый доллар от проданных телефонов и серверов приходилось 6 долларов за проданные свитчи и роутеры. Почему? Потому, что им в сущности нужна была инфраструктура для того, чтоб это работало. Для клиентов самое важное — это быстрый доступ к информации и мы сделали для этого больше других за очень короткий срок. Cisco начали с 0% в доле IP-телефонии и за 7 лет достигли доли в 35%.

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

Все эти 3 архитектуры пересекаются. Кто ещё мог такое сделать? Давайте подумаем о видео. Давайте подумаем о важности видео с точки зрения клиента. Что видео делает с сетью?

Когда руководство сказало IT-специалистам заняться вопросами видео, они за голову схватились. Требуются огромные усилия, чтобы выполнить эту работу. Вам нужно много мостов и инфраструктурных решений для этих целей. Теперь мы начали использовать видео и записывать его, поэтому мы и хотели иметь быстрый доступ к серверам, чтобы мы могли легко загружать всю свою бизнес-модель на серверы. И для этого нам необходимо, чтобы серверы работали постоянно.
Нам нужна мобильность. Что бы Вы делали со всеми этими Айпадами, Айфонами и с устройствами на базе Андроид? Ведь Вы хотите общаться с их помощью, верно? Вам захочется виртуализировать что-то из этого, так как Вы знаете, что Вы не сможете запустить рабочий стол Windows на Айпаде. Но если мы используем Citrix или VMware, то мы сможем запустить все наши приложения. Сейчас мы говорим о VXI, которая будет объединять все три архитектуры. Является ли такая работа преимуществом для Cisco? Конечно, без сомнений. Кто ещё сможет такое сделать? Никто, только одна компания в мире — Cisco.

Для сервис-провайдеров у нас есть отдельная архитектура сервис-провайдера, с возможностями видео, приложений, мобильности, беспроводной сети, построения IP-ядра (intellectual property core). Мы сможем заработать на этом деньги.

С AT&T был забавный случай. Я как-то их консультировал в Cisco. Ко мне обратился один из руководителей бухгалтерии AT&T на то время, и сказал, что у них есть проблема. На самом деле у них было 6033 проблемы. Что это значит? Он сказал, что ему постоянно приходится расширять границы своей сети из-за всех этих беспроводных технологий, добавлять всё больше и больше устройств, чтобы увеличивать мобильность. Из-за смартфонов потребление ресурсов сети увеличилось на 60 процентов, и ему необходимо расширять доступ к сети на 60% ежегодно. Ему приходится наращивать IP-ядро, хотя он никогда не думал, что ему придётся это делать. Ему уже потребовалось увеличить ресурсы на 30%, потому что все хотели использовать все эти устройства.
Я получаю всего 3% дохода от стоимости проекта, представьте себе. И это действительно очень тяжело, очень сложный вид бизнеса.

Эти стратегии позволяют им, возможно, воспользоваться некоторыми преимуществами над другими. Использовать свою собственную сеть. И если мы сможем уменьшить необходимость в расширении до 50, 25 или 4%, то мы станем сразу лучше, чем AT&T или кто-либо. Это то, что наша архитектура призвана выполнять.

У нас есть ещё одна архитектура для коммерческого сектора, для среднего и малого бизнеса. Нам нужно быстрое внедрение, чтобы упростить работу клиентов. Они не должны думать: «Я мелкий клиент, у меня не будет таких возможностей». Мелкие клиенты хотят того же, что и крупные. У них нет таких ресурсов, как у крупных клиентов, но у нас есть целая стратегия, построенная на SMB – сетевом протоколе прикладного уровня для удалённого доступа к файлам и сетевым ресурсам. И мы больше фокусируемся на этом.

На развитие архитектуры уходит много денег, но руководители понимают, что она важна для гибкости, для бизнеса, так как волны клиентских потребностей накатывают все чащё и чащё. Волнует ли это IT? Нет, их это не волнует. Так как для них Cisco является просто дорогой компанией, вот что они думают о Cisco. Может им это и нравится и они хотели бы, чтобы у них был CCI (индекс товарного капитала), как у других. Но эти люди хотят продолжать вкладываться в своё обучение, чтобы потом получить свою оплату за это. Но архитектура действительно имеет значение для лидеров бизнеса, для гибкости бизнеса. Поскольку эти волны, эти изменения, происходят всё быстрее и быстрее.

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

Мы помогаем людям с облачными технологиями. Та же стратегия дата-центров, которая работает здесь, на самом деле работает для них. Таким образом они могут размещать и принимать данные. И наше решение HCS, это на самом деле каждый компонент, о котором мы будем говорить в групповой архитектуре, это тот же компонент, что и в серверной архитектуре. Отличие в том, что у серверной лучше инструменты управления. Наша архитектура уникальна. У нас больше портов, чем продуктов в Walmart. В следующий раз, как пойдёте в Walmart, представьте себе масштабы Cisco. У нас для всего есть SKU (идентификатор товарной позиции, артикул). На каждый продукт, у нас есть минимум 40 SKU, и это важно для клиентов. Но об этом мы ещё поговорим более подробно.

Многие говорят, что Microsoft — враг Cisco. Так и есть. Мы враги по-разному. Майкрософт властвует на рабочем столе, и когда рабочий стол меняется, продажи компьютеров падают. Они будут вынуждены уделять больше внимания видео и голосу, чтобы защитить свой товар, а мы будем стараться удержать свои позиции в этом вопросе, так как наш бизнес на этом держится. Мы существуем за счёт умных сетей. Майкрософт говорят: «Эй, нам нужны свитчи от Juniper, роутеры от HP и ещё это и вон то, принимайте наше предложение!». Для них не важны сетевые технологии и роутеры, они пишут собственное программное обеспечение.

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

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

Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас оформив заказ или порекомендовав знакомым, 30% скидка для пользователей Хабра на уникальный аналог entry-level серверов, который был придуман нами для Вас:Вся правда о VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps от $20 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле? Только у нас 2 х Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 ТВ от $249 в Нидерландах и США! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?

Let's block ads! (Why?)

[Из песочницы] Руководство инструктора к книге «Программирование: Принципы и практика с использованием C++»

[Перевод] ITSM ликбез: Пользователи и Заказчики — кто скрывается за этими именами?

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

image

Автор: Дена Уайдер-Фреиден (Dena Wieder-Freiden)
Публикация 18 октября 2016 года
в разделе Service Desk богов на sysaid

Роза пахнет розой, хоть розой назови её, хоть нет.
(У.Шекспир)

Я не часто начинаю свои записи в блоге про Управление ИТ услугами с цитат Уильяма Шекспира, но в его “Ромео и Джульетте” есть идеально подходящая для текущей темы фраза: “Роза пахнет розой, хоть розой назови её, хоть нет”. К сожалению, как и герои Шекспира, находящие трагическую кончину, человеческое сообщество и в реальности зациклено на именах, ярлыках и словах, которые использует. Так из-за подмены авторами ITIL значений у некоторых общепринятых слов на специфичные для ITIL (например, “инцидент” и “проблема”), многие начинают путаться в смысле сказанного. Ситуация так похожа на пьесу Шекспира, когда весь накопленный поколениями ком проблем в отношениях между семьями Монтекки и Капулетти, разрушается значением любви для юноши и девушки друг к другу.

Итак… Пользователи и Заказчики в Управлении ИТ услугами.


Давайте сосредоточимся сейчас на одной важной идее, которая, на мой взгляд, вызывает множество проблем из-за особенностей терминологии. В ITIL понятия “пользователь” и “заказчик” имеют сильно различающиеся значения.

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

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

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

Выбор автомобиля


И так, представим, что Ваш автомобиль был украден, страховая компания присылает чек с компенсацией и Вы идете покупать замену. Вы обходите автодилеров в округе и на глаза попадается прекрасная сверкающая красная машина с симпатичной скачущей лошадкой на эмблеме.”О, да”, — думаете Вы: “я хочу ее получить”. Затем они говорят сколько стоит эта Феррари и Вы уезжаете домой на купленном в кредит подержанном Форде кормить своих детей.

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

История с игрушкой


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

В этом примере взрослые выступают в качестве заказчиков, а дети — пользователей.

Различие ролей означает не только то что это разные люди.


В ИТ сценариях и в обычной жизни важно понимать, что заказчики и пользователи — это роли не обязательно выполняемые разными людьми. Вы можете выбирать выгодную опцию, выступая в роли заказчика, и ощущать недовольство позже из-за недостаточных функциональности, надёжности или поддержки (или отсутствия), выступая уже в роли пользователя.

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

Или для дома Вы можете иметь предложение от энергетической компании за дополнительные 400 долларов в месяц за гарантию стабильной и непрерывной подачи электроэнергии. Это может быть так много для вашего внутреннего заказчика и Вы отклоните это предложение. Потом когда спустя шесть месяцев, когда электричество “закончится” ваш пользователь будет огорчен, не то энергетической компанией, не то самим собой.

Как их не назовешь, а они будут все теми же двумя ролями


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

И это все не заканчивается, когда услуга запущена в эксплуатацию, текущая поддержка и запросы на улучшение п рождаются в виде диалога с обоими группами. ITIL предлагает каналов для обсуждений с ними обоими: и с заказчиками и с пользователями. Заключение и оценка выполнения соглашений об уровне обслуживания (SLA), процедуры по улучшению услуг, управление изменениями и т.д. взаимодействуют заказчиками. С пользователями же основной канал сказали это Служба поддержки (Service Desk), которая кроме приема звонков о проблемах с работой чего-либо также может собирать жалобы и пожелания пользователей и передать их в процедуры по улучшению услуг.

Передовые организации уже предприняли шаги для установления и поддержания контакта с обоими типами заинтересованных лиц в услугах. А Вы тоже так делаете?

Let's block ads! (Why?)

Британские интернет-провайдеры протянут оптоволокно в 3 миллиона домов

По данным исследования аналитической компании IHS Markit, Великобритания занимает третье место с конца (среди стран Европы) по количеству оптоволоконных подключений. Еще одна проблема Соединенного королевства — медленный интернет в сельской местности, о чем мы недавно писали в блоге.

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


/ Flickr / Groman123 / CC

В чем суть проекта


British Telecom (BT) объявила об ускоренном внедрении широкополосного интернета для миллиона домов. Openreach — дочерняя компания BT, которая контролирует основные интернет-сети Британии, опубликовала план по подключению 3 млн зданий к оптоволоконной сети (FTTP) до 2020 года.

Как сообщают в Times, сейчас только 3% домов Англии подключены к FTTP. Для сравнения: в Испании таких домов 79%. Для большинства жителей Британии выход в интернет обеспечивается с помощью устаревших медных кабелей, которые проложили BT несколько десятилетий назад. Средняя скорость интернета в стране равна 16,5 Мбит/с, а FTTP-соединения обеспечат скорость до 1 Гбит/с.

В рамках программы Fiber First корпорация Openreach наймет 3000 человек для развертывания сети в восьми крупных городах Британии: Бирмингем, Бристоль, Кардифф, Эдинбург, Лидс, Ливерпуль, Лондон и Манчестер. Работы планируют начать в апреле 2018 года.

Исполнительный директор организации Клайв Селли (Clive Selley) утверждает, что проект — первый этап для достижения цели в 10 миллионов подключенных домов к 2025 году. На вопрос о стоимости проекта Селли не назвал точную сумму. Тем не менее, он утверждает, что она будет «очень большой»: только стартовый бюджет составит несколько сотен миллионов фунтов стерлингов. Как сообщает The Register, финальная стоимость будет варьироваться от 3 до 6 миллиардов фунтов.

Сложности проекта


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

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

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

Стоимость одного оптоволоконного подключения в черте города оценивается в 300–400 фунтов стерлингов, а подключения в пригороде обойдутся еще дороже.


/ Flickr / Dennis van Zuijlekom / CC

Что готовят конкуренты


Среди соперников BT и ее подразделения Openreach выделяются Vodafone, TalkTalk, City Fibre и Virgin Media, которые тоже строят оптоволоконные сети.

Спустя несколько дней после публикации плана Openreach в TalkTalk заявили, что инвестируют крупную сумму в оптоволоконную инфраструктуру и доставят интернет в 3 миллиона домов и организаций. Исполнительный директор компании Тристия Харрисон (Tristia Harrison) подчеркивает, что в TalkTalk займутся пригородными районами, а BT — городами, поэтому планы организаций не будут пересекаться.

Еще один оператор Hyperoptic, который считается вторым (после Openreach) крупным провайдером оптоволокна в Англии, скептически относится к планам своего главного конкурента. Hyperoptic заявляют, что уже «много лет возглавляют переход на оптоволокно» (они уже предоставили доступ к оптоволоконной сети каждому седьмому жителю Лондона и Манчестера). Openreach же, по их словам, пытается представить дело так, будто до их проекта подобных инициатив в стране не существовало. Кстати, в Hyperoptic подтверждают намерение подключить к оптоволоконной сети 2 миллиона домов к 2020 году и 5 миллионов — к 2025 году.

Что касается CityFibre, то представители этой компании вообще считают поведение Openreach отчаянным шагом, сделанным в ответ на растущую конкуренцию со стороны других игроков рынка. В своем официальном обращении CityFibre подчеркивает, что их партнерский союз с Vodafone планирует обеспечить 5 миллионов домов и предприятий (20% рынка) широкополосным интернетом к 2025 году — на фоне этих заявлений планы Openreach уже не кажутся такими грандиозными.

Такую конкуренцию одобрили в телекоммуникационной корпорации Ofcom и в правительстве. А министр цифровых технологий, культуры, СМИ и спорта Великобритании Мэттью Хэнкок (Matthew Hancock) назвал эти проекты большим шагом на пути к тому, чтобы подготовить Англию к «оптоволоконному будущему». Он также подчеркнул, что для достижения этой цели правительство работает со многими операторами, в том числе с Openreach, Virgin, CityFibre, Gigaclear, TalkTalk.

Другие решения


Развитие 4G (как альтернативы оптоволоконной сети) в Великобритании тоже является приоритетным направлением. По данным отчета Ofcom Connected Nations за 2017 год, только в 7 из 10 регионов Англии есть доступ к 4G. Технология покрывает 63% страны, в черте города 4G охватывает 90% территории, а в сельской местности — 57%. Ситуация с охватом дорог примерно та же: 4G покрывает 68% из них. Среди операторов выделяются компании EE, Vodafon, Three и O2.

Один из совместных проектов в этом направлении — проведение 4G-сети в метро Лондона к 2019 году. Летом 2018 года основные операторы Британии тестировали технологию на линиях Waterloo и City. В результате тестов поставщикам удалось обеспечить бесперебойный 4G-интернет на протяжении поездки длиной 1,5 мили.

Компания TfL рассказала The Register, что тестирование (которое включало и развертывание соответствующей инфраструктуры) проводилось для того, чтобы определить предполагаемые сроки развертывания 4G. Тоннели в лондонском метрополитене очень узкие, поэтому так важно было запустить тестовый проект и оценить, какие трудности могут возникнуть при проведении работ, прежде чем приступать к полномасштабному развертыванию проекта.

4G станет основой для реализации другого проекта — Emergency Services Network (ESN). Представитель TfL отметил, что организация проектирует и устанавливает инфраструктуру так, чтобы ее можно было использовать и для обеспечения 4G-интернета в метро, и для ESN.

Еще одно 4G-решение нацелено на улучшение связи в отдаленных районах страны. Компания EE планирует установить 4G-антенны в 580 тысячах сельских домов Великобритании. Устройство представляет собой небольшой ящик размером с коробку из-под обуви, который закрепляется на крыше, как обычная антенна. Такое решение подойдет для территорий, куда на данный момент невозможно протянуть оптоволоконный кабель. Стоимость антенны составит от 35 до 100 фунтов стерлингов.

В корпорации утверждают, что во время тестов в Камбрии (графство на северо-западе страны) скорость интернета достигла 100 Мбит/с. Дальнейшие планы EE — покрыть 4G-сетью 95% Соединенного королевства к 2020 году.

Как отмечает член парламента Рори Стюарт (Rory Stewart), основная сложность при обеспечении интернетом пригородов и деревень — удаленность домов друг от друга. Протягивать оптоволоконный кабель в таком случае не очень выгодно. А решение EE поможет преодолеть эту сложность, чтобы жители Камбрии и других районов получили доступ к высокоскоростному интернету.

В BBC утверждают, что в течение нескольких лет многие операторы Англии: от BT и TalkTalk до CityFibre и Hyperoptic, будут работать над улучшением ситуации с доступом в интернет по всей Великобритании. И их конкуренция должна привести к значительным переменам в сетевой инфраструктуре страны.

P.S. Несколько материалов по теме из нашего блога на Хабре:


Дополнительные статьи из нашего корпоративного блога на сайте VAS Experts:

Let's block ads! (Why?)

Моделирование динамических систем: задача внешней баллистики

Горе от ума, или Почему отличники пишут непонятный код

Как управлять инфраструктурой в сотни серверов и избежать проблем: 5 советов от инженеров King Servers

В блоге на Хабре мы много пишем о построении ИТ-инфраструктуры — например, раскрываем вопросы выбора дата-центров в России и США. Сейчас в рамках King Servers работают сотни физических и тысячи виртуальных серверов. Сегодня наши инженеры делятся советами по управлению инфраструктурой таких размеров.

Автоматизация очень важна


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

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

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

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

Резервирование и бэкапы спасают в критических ситуациях


В случае крупной инфраструктуры резервирование становится еще более важным, поскольку в случае сбоя пострадает большое количество пользователей. Стоит резервировать:
  • Мониторинг серверов — необходимо не только создать систему мониторинга сбоев, но и использовать инструменты «мониторинга мониторинга».
  • Инструменты управления.
  • Каналы связи — если в вашем дата-центре лишь один провайдер, то в случае сбоя все ваше железо будет полностью отрезано от мира. Недавно мы столкнулись со сбоев канала в нашем ЦОД в Нидерландах — если бы там не было резервирования канала, то сервис для сотен наших клиентов был бы остановлен, с соответствующими последствиями для бизнеса.
  • Линии электропитания – в современных ЦОД есть возможность подведения 2 независимых линий электропитания к стойкам. Не стоит этим пренебрегать и экономить на дополнительных блоках питания для серверов. В случае если у вас уже куплено много серверов, в которые невозможно установить запасной блок питания – можно установить оборудование для автоматического ввода резерва, которое предназначено для подключения оборудования с одним блоком питания к 2 вводам.
  • Любое оборудование требует периодического технического обслуживания, и вероятность того, что в ЦОД будут проводится работы с отключением одной из линий питания – 100%
  • Если повезет – работы будут не на вашей линии питания, но рисковать не стоит.
  • Мало того, что сервисы могут быть недоступны несколько часов, так еще и существует вероятность, что часть серверов после резкого отключения питания сами не поднимутся, и потребуется вмешательство инженеров.
  • Железо — даже в случае качественного оборудования всегда есть вероятность отказа, поэтому наиболее важные элементы должны дублироваться и на уровне аппаратного обеспечения. К примеру, в серверах чаще всего отказывают диски, так что использование RAID-массивов с резервированием — хорошая идея, как и резервирование на уровне сети, когда один сервер подключен к разных свитчам, что позволяет не терять трафик при выходе одного устройства из строя. Также необходимо иметь хотя бы минимальный запас запасных частей. Выход из строя комплектующих у качественного оборудования маловероятен, но не невозможен.

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

Составление документации и логи


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

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

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

Важно анализировать время реакции инженеров дата-центра


Все адекватные современные дата-центры предоставляют услугу remote hands, в рамках которой при возникновении проблем владелец серверов может попросить инженеров на площадке произвести с оборудованием необходимые действия. Но не всегда в итоге площадки оказывают ее качественно. Причин может быть много, одна из самых частых — высокая загрузка специалистов, или отсутствие некоторых инженеров на площадке (один из дата-центров в США предлагал нам такую опцию — выезд инженера в течение рабочего дня), но в критических ситуация время реакции очень важно, а возникнуть проблема может не только в рабочее время.

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

Также вполне может оказаться, что после того как вы перевезли оборудование и аккуратно уложили все кабели, по прошествии пары лет и нескольких десятков запросов на помощь в рамках услуги remote hands картина будет выглядеть так:

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

Не нужно стремиться к экономии, экспериментировать лучше аккуратно


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

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

В своем проекте мы уже многие годы используем продукцию компании SuperMicro — с этими серверами не случалось каких-то серьезных беспричинных сбоев. Также не так давно очень осторожно начали работать с оборудованием Dell. У продукции этой компании отличная репутация, но резко наращивать объемы работы с новым железом всегда рискованно, поэтому мы двигаемся постепенно.

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

Ничем хорошим это не закончится, особенно, если инфраструктуру используют внешние заказчики – в сфере хостинга нередка ситуация, когда пользователь покупает виртуальный сервер для бизнеса, но забывает делать бэкапы или не тестирует их развертывание (так и выглядит экономия малого бизнеса на администраторах). Если при этом еще и физический сервер будет собран наполовину из десктопных компонентов, то очень скоро произойдет сбой с полной потерей данных — это может просто убить чей-то бизнес. Такого допускать нельзя.

Больше полезных ссылок и материалов от King Servers:


Let's block ads! (Why?)

Интеграция Asterisk и Битрикс24

В сети есть разные варианты интеграции IP-АТС Asterisk и CRM Битрикс24, но мы, все таки, решили написать свою.
По функционалу все стандартно:

  • Кликом на ссылку с номером телефона клиента в Битрикс24, Asterisk соединяет внутренний номер пользователя, от имени которого это клик совершен, с номером телефона клиента. 
В Битрикс24 фиксируется запись о звонке и по окончании вызова подтягивается запись разговора.
  • На Asterisk поступает звонок извне — в интерфейсе Битрикс24 показываем карточку клиента тому сотруднику, на номер которого этот звонок прилетел.
    Если такого клиента нет, откроем карточку создания нового лида.
    Как только звонок завершен, отражаем это в карточке и подтягиваем запись разговора.

Под катом расскажу как все настроить у себя и дам линк на github — да-да, забирайте и пользуйтесь!

Общее описание.


Свою интеграцию мы назвали CallMe.
CallMe — это небольшое веб-приложение, написанное на PHP.

Используемые технологии и сервисы:


  • PHP 5.6
  • PHP AMI-библиотека (https://github.com/marcelog/PAMI)
  • Composer
  • Nginx + php-fpm
  • supervisor
  • AMI (Asterisk menegement interface)
  • Вебхуки Bitrix (упрощенная реализация REST API)

Предварительная настройка.


На сервере с Astrisk необходимо установить web-сервер (у нас это nginx+php-fpm), supervisor и git.
Команда для установки (CentOS):
yum install nginx php-fpm supervisor git

Переходим директорию, доступную веб-серверу, тянем из гита приложение и выставляем нужные права на папку:

cd /var/www
git clone https://github.com/ViStepRU/callme.git
chown nginx. -R callme/

Далее настроим nginx, наш конфиг разместился в

/etc/nginx/conf.d/pbx.vistep.ru.conf
server {
        server_name www.pbx.vistep.ru pbx.vistep.ru;
        listen *:80;
        rewrite ^  https://pbx.vistep.ru$request_uri? permanent;
}

server {
#        listen *:80;
#       server_name pbx.vistep.ru;


        access_log /var/log/nginx/pbx.vistep.ru.access.log main;
        error_log /var/log/nginx/pbx.vistep.ru.error.log;

    listen 443 ssl http2;
    server_name pbx.vistep.ru;
    resolver 8.8.8.8;
    ssl_stapling on;
    ssl on;
    ssl_certificate /etc/letsencrypt/live/pbx.vistep.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/pbx.vistep.ru/privkey.pem;
    ssl_dhparam /etc/nginx/certs/dhparam.pem;
    ssl_session_timeout 24h;
    ssl_session_cache shared:SSL:2m;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers kEECDH+AES128:kEECDH:kEDH:-3DES:kRSA+AES128:kEDH+3DES:DES-CBC3-SHA:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv2;
    ssl_prefer_server_ciphers on;
    add_header Strict-Transport-Security "max-age=31536000;";
    add_header Content-Security-Policy-Report-Only "default-src https:; script-src https: 'unsafe-eval' 'unsafe-inline'; style-src https: 'unsafe-inline'; img-src https: data:; font-src https: data:; report-uri /csp-report";
        
        root /var/www/callme;
        index  index.php;
        location ~ /\. {
                deny all; # запрет для скрытых файлов
        }

        location ~* /(?:uploads|files)/.*\.php$ {
                deny all; # запрет для загруженных скриптов
        }

        location ~* ^.+\.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|atom|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ {
                access_log off;
                log_not_found off;
                expires max; # кеширование статики
        }

        location ~ \.php {
                root /var/www/callme;
                index  index.php;
                fastcgi_pass unix:/run/php/php5.6-fpm.sock;
        #       fastcgi_pass 127.0.0.1:9000;
                fastcgi_index index.php;
                fastcgi_param SCRIPT_FILENAME $document_root/$fastcgi_script_name;
                include /etc/nginx/fastcgi_params;
                }
}


Разбор конфига, вопросы безопасности, получение сертификата и даже выбор web-сервера я оставлю за рамками статьи — об этом много написано. У приложения нет ограничений, оно работает и по http и по https.
У нас — https, сертификат let's encrypt.

Если вы все сделали правильно, то перейдя по ссылке должны увидеть нечто подобное

Настройка Битрикс24.


Создадим два вебхука.
Входящий вебхук.
Под учетной записью администратора (с id 1) идем по пути:
Приложения -> Вебхуки -> Добавить вебхук -> Входящий вебхук

Заполняем параметры входящего вебхука как на скринах:

И жмем сохранить.
После сохранения Битрикс24 предоставит URL входящего вебхука, например:

Сохраните себе ваш вариант URL без завершающего /profile/ — он будет использоваться в приложении для работы с входящими звонками.
У меня это
https://b24-xsynia.bitrix24.ru/rest/1/7eh61lh8pahw0fwt

Исходящий вебхук.
Приложения -> Вебхуки -> Добавить вебхук -> Исходящий вебхук
Подробности снова на скринах:

Сохраняем и получаем код авторизации

У меня это
xcrp2ylhzzd2v43cmfjqmkvrgrcbkni6
его тоже нужно скопировать себе, он нужен для совершения исходящих звонков.

Важно!

На сервере Битрикс24 должен быть настроен ssl-сертификат (можно использовать letsencrypt), иначе api битрикса не будет работать. Если у вас облачная версия, можете не волноваться — там уже есть ssl.

Настройка asterisk.


Для успешного взаимодействия Asterisk и Bitrix24 нам нужно добавить AMI-пользователя callme в manager.conf:
[callme]
secret = JD3clEB8_f23r-3ry84gJ
deny = 0.0.0.0/0.0.0.0
permit = 127.0.0.1/255.255.255.0
permit= 10.100.111.249/255.255.255.255
permit = 192.168.254.0/255.255.255.0
read = system,call,log,verbose,agent,user,config,dtmf,reporting,cdr,dialplan
write = system,call,agent,log,verbose,user,config,command,reporting,originate


Далее есть несколько хитростей, которые потребуется внедрить посредствам dialplan (у нас это extensions.ael)
Привожу весь файл, а после дам пояснения:
globals {
    WAV=/var/www/pbx.vistep.ru/callme/records/wav; //Временный каталог с WAV
    MP3=/var/www/pbx.vistep.ru/callme/records/mp3; //Куда выгружать mp3 файлы
    URLRECORDS=https://pbx.vistep.ru/callme/records/mp3;
    RECORDING=1; // Запись, 1 - включена.
};

macro recording(calling,called) {
        if ("${RECORDING}" = "1"){
              Set(fname=${UNIQUEID}-${STRFTIME(${EPOCH},,%Y-%m-%d-%H_%M)}-${calling}-${called});
              Set(datedir=${STRFTIME(${EPOCH},,%Y/%m/%d)});
              System(mkdir -p ${MP3}/${datedir});
              System(mkdir -p ${WAV}/${datedir});
              Set(monopt=nice -n 19 /usr/bin/lame -b 32  --silent "${WAV}/${datedir}/${fname}.wav"  "${MP3}/${datedir}/${fname}.mp3" && rm -f "${WAV}/${fname}.wav" && chmod o+r "${MP3}/${datedir}/${fname}.mp3");
              Set(FullFname=${URLRECORDS}/${datedir}/${fname}.mp3);
              Set(CDR(filename)=${fname}.mp3);
              Set(CDR(recordingfile)=${fname}.wav);
              Set(CDR(realdst)=${called});
              MixMonitor(${WAV}/${datedir}/${fname}.wav,b,${monopt});

       };
};


context incoming {
888999 => {
        &recording(${CALLERID(number)},${EXTEN});
        Answer();
        ExecIF(${CallMeCallerIDName}?Set(CALLERID(name)=${CallMeCallerIDName}):NoOp()); // выставляем CallerID если узнали его у Битрикс24
        Set(CallStart=${STRFTIME(epoch,,%s)});  
        Queue(Q1,tT);
        Set(CallMeDISPOSITION=${CDR(disposition)}); 
        Hangup();
        }

h => {
    Set(CDR_PROP(disable)=true); 
    Set(CallStop=${STRFTIME(epoch,,%s)}); 
    Set(CallMeDURATION=${MATH(${CallStop}-${CallStart},int)}); 
    ExecIF(${ISNULL(${CallMeDISPOSITION})}?Set(CallMeDISPOSITION=${CDR(disposition)}):NoOP(=== CallMeDISPOSITION already was set ===));  
    System(curl -s https://pbx.vistep.ru/CallMeOut.php --data action=sendcall2b24 --data call_id=${CallMeCALL_ID} --data-urlencode FullFname=${FullFname} --data CallIntNum=${CallIntNum} --data CallDuration=${CallMeDURATION} --data-urlencode CallDisposition=${CallMeDISPOSITION});  
}

}




context default {

_X. => {
        Hangup();
        }
};


context dial_out {

_[1237]XX => {
        &recording(${CALLERID(number)},${EXTEN});
        Set(__CallIntNum=${CALLERID(num)})
        Set(CallStart=${STRFTIME(epoch,,%s)});
        Dial(SIP/${EXTEN},,tTr);
        Hangup();
        }

_11XXX => {
        &recording(${CALLERID(number)},${EXTEN});
        Set(CallStart=${STRFTIME(epoch,,%s)});
        Set(__CallIntNum=${CALLERID(num)});
        Dial(SIP/${EXTEN:2}@toOurAster,,t);
        Hangup();
        }

_. => {
        &recording(${CALLERID(number)},${EXTEN});
        Set(__CallIntNum=${CALLERID(num)})
        Set(CallStart=${STRFTIME(epoch,,%s)});
        Dial(SIP/${EXTEN}@toOurAster,,t);
        Hangup();
        }

h => {
        Set(CDR_PROP(disable)=true);
        Set(CallStop=${STRFTIME(epoch,,%s)});
        Set(CallMeDURATION=${MATH(${CallStop}-${CallStart},int)});
        if(${ISNULL(${CallMeDISPOSITION})}) {
          Set(CallMeDISPOSITION=${CDR(disposition)});
        }
        System(curl -s http://pbx.vistep.ru/CallMeOut.php --data action=sendcall2b24 --data call_id=${CallMeCALL_ID} --data-urlencode FullFname=${FullFname} --data CallIntNum=${CallIntNum} --data CallDuration=${CallMeDURATION} --data-urlencode CallDisposition=${CallMeDISPOSITION});
}

};



Начнем с самого начала: директива globals.
Переменная URLRECORDS хранит в себе URL к файлам записей разговоров, по которому Bitrix24 будет их подтягивать в карточку контакта.

Далее нам интересен макрос макрос recording.
Здесь, помимо записи разговоров, мы установим переменную FullFname.

Set(FullFname=${URLRECORDS}/${datedir}/${fname}.mp3);

Она хранит полный URL к конкретному файлу (макрос вызывается везде).

Разберем исходящий звонок:

_. => {
        &recording(${CALLERID(number)},${EXTEN});
        Set(__CallIntNum=${CALLERID(num)})
        Set(CallStart=${STRFTIME(epoch,,%s)});
        Dial(SIP/${EXTEN}@toOurAster,,t);
        Hangup();
        }

h => {
        Set(CDR_PROP(disable)=true);
        Set(CallStop=${STRFTIME(epoch,,%s)});
        Set(CallMeDURATION=${MATH(${CallStop}-${CallStart},int)});
        if(${ISNULL(${CallMeDISPOSITION})}) {
          Set(CallMeDISPOSITION=${CDR(disposition)});
        }
        System(curl -s http://pbx.vistep.ru/CallMeOut.php --data action=sendcall2b24 --data call_id=${CallMeCALL_ID} --data-urlencode FullFname=${FullFname} --data CallIntNum=${CallIntNum} --data CallDuration=${CallMeDURATION} --data-urlencode CallDisposition=${CallMeDISPOSITION});
}


Допустим мы звоним на 89991234567, первым делом попадаем сюда:
&recording(${CALLERID(number)},${EXTEN});

т.е. вызывается макрос записи разговора и проставляются нужные переменные.

Далее

        Set(__CallIntNum=${CALLERID(num)})
        Set(CallStart=${STRFTIME(epoch,,%s)});


записываем кто инициировал звонок и фиксируем время старта звонка.
И по его завершению, в специальном контексте h
h => {
        Set(CDR_PROP(disable)=true);
        Set(CallStop=${STRFTIME(epoch,,%s)});
        Set(CallMeDURATION=${MATH(${CallStop}-${CallStart},int)});
        if(${ISNULL(${CallMeDISPOSITION})}) {
          Set(CallMeDISPOSITION=${CDR(disposition)});
        }
        System(curl -s http://pbx.vistep.ru/CallMeOut.php --data action=sendcall2b24 --data call_id=${CallMeCALL_ID} --data-urlencode FullFname=${FullFname} --data CallIntNum=${CallIntNum} --data CallDuration=${CallMeDURATION} --data-urlencode CallDisposition=${CallMeDISPOSITION});
}


отключаем запись в таблицу CDR для этого экстеншена (не нужно оно там), выставляем время завершения звонка, вычисляем продолжительность, если результат звонка не известен — ставим (переменная CallMeDISPOSITION) и, последним шагом, шлем все битриксу через системный curl.

И еще немного магии — входящий звонок:

888999 => {
        &recording(${CALLERID(number)},${EXTEN});
        Answer();
        ExecIF(${CallMeCallerIDName}?Set(CALLERID(name)=${CallMeCallerIDName}):NoOp()); // выставляем CallerID если узнали его у Битрикс24
        Set(CallStart=${STRFTIME(epoch,,%s)}); // начинаем отсчет времени звонка
        Queue(Q1,tT);
        Set(CallMeDISPOSITION=${CDR(disposition)}); 
        Hangup();
        }


Здесь нас интересует только одна строка.
ExecIF(${CallMeCallerIDName}?Set(CALLERID(name)=${CallMeCallerIDName}):NoOp());

Она говорит АТС установить CallerID(name) равным переменной CallMeCallerIDName.
Сама переменная CallMeCallerIDName, в свою очередь, устанавливается приложением CallMe (если в Bitrix24 есть ФИО для номера позвонившего — установим в качестве CallerID(name), нет — ничего не будем делать).

Настройка приложения.


Файл настроек приложения — /var/www/pbx.vistep.ru/config.php
Описание параметров приложения:
  • CallMeDEBUG — если 1, то в лог файл будут писаться все события, обрабатываемые приложением, 0 — ничего не пишем
  • tech — SIP/PJSIP/IAX/etc
  • authToken — токен авторизации битрикс24, код авторизации исходящего вебхука
  • bitrixApiUrl — URL входящего вебхука, без profile/
  • extentions — список внешних номеров
  • context — контекст для оригинации звонка
  • listener_timeout — скорость обработки событий от asterisk
  • asterisk — массив с настройками подключения к астериску:
  • host — ip или hostname сервера астериск
  • scheme — схема подключения (tcp://, tls://)
  • port — порт
  • username — имя пользователя
  • secret — пароль
  • connect_timeout — таймаут подключения
  • read_timeout — таймаут чтения

пример файла настроек:
 1, // дебаг сообщения в логе: 1 - пишем, 0 - не пишем
        'tech' => 'SIP',
        'authToken' => 'xcrp2ylhzzd2v43cmfjqmkvrgrcbkni6', //токен авторизации битрикса
        'bitrixApiUrl' => 'https://b24-xsynia.bitrix24.ru/rest/1/7eh61lh8pahw0fwt', //url к api битрикса (входящий вебхук)
        'extentions' => array('888999'), // список внешних номеров, через запятую
        'context' => 'dial_out', //исходящий контекст для оригинации звонка
        'asterisk' => array( // настройки для подключения к астериску
                    'host' => '10.100.111.249',
                    'scheme' => 'tcp://',
                    'port' => 5038,
                    'username' => 'callme',
                    'secret' => 'JD3clEB8_f23r-3ry84gJ',
                    'connect_timeout' => 10000,
                    'read_timeout' => 10000
                ),
        'listener_timeout' => 300, //скорость обработки событий от asterisk

);

Настройка supervisor.


Supervisor служит для запуска процесса-обработчика событий от Asterisk CallMeIn.php, который отслеживает входящие звонки и взаимодействует с Битрикс24 (показать карточку, скрыть карточку и т.д.).
Файл настроек, который необходимо создать:
/etc/supervisord.d/callme.conf
[program:callme]
command=/usr/bin/php CallMeIn.php
directory=/var/www/pbx.vistep.ru
autostart=true
autorestart=true
startretries=5
stderr_logfile=/var/www/pbx.vistep.ru/logs/daemon.log
stdout_logfile=/var/www/pbx.vistep.ru/logs/daemon.log

Запуск и рестарт приложения:
supervisorctl start callme
supervisorctl restart callme

просмотр статуса работы приложения:
supervisorctl status callme
callme RUNNING pid 11729, uptime 17 days, 16:58:07

Заключение


Получилось достаточно сложно, но уверен — опытный администратор сумеет внедрить у себя и порадовать своих пользователей.
Как обещал, линк на гитхаб — github.com/ViStepRU/callme
Вопросы, пожелания — прошу в комменты. Также если интересно как шла разработка этой интеграции, напишите, а в очередной статье я постараюсь раскрыть все более детально.

Let's block ads! (Why?)

[Из песочницы] Научиться программировать становится сложнее

Привет, Хабр! Представляю вашему вниманию перевод статьи Аллена Б. Дауни, автора таких книг как Think Python, Think Java, Think Bayes и других, опубликованной в личном блоге автора.

Я написал несколько книг, в которых c использованием языка программирования Python объясняются темы вроде Байесовской статистики и цифровой обработки сигналов. В дополнение к книгам читатели могут загрузить код с GitHub. Для того, чтобы использовать этот код, нужно знать некоторые основы Python. То есть, у читателей должен быть компьютер, на котором установлен интерпретатор этого языка и необходимые библиотеки, они должны знать, как загрузить код с GitHub, а еще они должны знать, как запустить код, который они загрузили.

Пытаясь проделать все это, многие читатели начинают испытывать трудности.

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

Я с пониманием отношусь к их чувствам. В определенном смысле их разочарование оправданно. Загрузить и запустить код не должно быть так сложно. Иногда они винят в сложностях Python, а иногда и меня. И я считаю, что это не совсем заслуженно.

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

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

С тех пор три вещи сделали путь от пользователя до программиста сложнее.

  1. Компьютеры перестали продаваться с предустановленными по умолчанию средами разработки. Теперь любому, кто хотел научиться программировать, приходилось сначала установить среду разработки. И это больший барьер, чем могло бы показаться. Многие пользователи вообще никогда ничего не устанавливали, не знали как это делать и могли не обладать необходимыми для этого правами. Сейчас устанавливать программы стало гораздо легче, чем это было раньше, но возможные ошибки при установке никуда не делись и это может доставлять пользователям серьезные неудобства. Если кто-то хочет научиться программировать, он не должен для этого предварительно изучать администрирование системы.
  2. Пользовательские интерфейсы сильно отошли от командной строки в сторону графических интерфейсов. Последними, как правило, проще пользоваться, но они не отображают информацию о том, что происходит в системе на самом деле. Когда пользователю не требуется знать все эти детали, в подобном поведении нет ничего страшного. Но проблема в том, что графические интерфейсы скрывают информацию, которую необходимо знать программистам. Поэтому когда пользователь начинает учиться программировать, он внезапно сталкивается с вещами, которые обычно от него скрыты. Если кто-то просто хочет научиться программировать, он не должен для этого изучать устройство операционных систем.
  3. Облачные технологии только осложняют ситуацию. Люди, использующие веб приложения, часто имеют очень смутное представление о том, где их данные хранятся и с помощью каких приложений они могут получить к ним доступ. Многие пользователи, особенно на мобильных девайсах, не видят различий между операционными системами, приложениями, веб-браузерами и веб-приложениями. Когда они загружают данные или отправляют их через интернет, они часто не до конца понимают, откуда именно эти данные поступают и куда попадают. А когда что-то устанавливают, часто не до конца понимают, что именно устанавливается и куда.

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

Хорошо, и что же мы можем с этим поделать? Вот несколько вариантов:

  1. Назад в будущее. Во-первых, можно создавать компьютеры (как мой Commodore 64), которые бы разрушали барьер между использованием устройства и его программированием. Одной из предпосылок к созданию Raspberry Pi, по словам Эбена Аптона, было желание создать среду, которая бы превращала пользователей в программистов.
  2. Встретиться с болью лицом к лицу. Другой подход — учить студентов как настраивать и использовать среду разработки до того, как они начали программировать (или одновременно с этим).
  3. Отсрочить боль. Третий вариант предполагает использование облачных сервисов, чтобы студенты могли сразу начать программировать и на время отложить подготовку собственной среды разработки.

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

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

  1. Интерактивные учебники, позволяющие запускать код прямо в браузере, как например эта адаптация книги How To Think Like a Computer Scientist
  2. Cреды разработки, работающие через браузер, как например PythonAnywhere
  3. Образы виртуальных машин с уже настроенными и готовыми к работе средами разработки, которые пользователь может загрузить и запустить у себя (при условии, конечно, что он может установить программное обеспечение для запуска виртуальной машины).
  4. Сервисы вроде Binder, представляющие собой среду выполнения в облаке, и позволяющие пользователям получить доступ к некоторым функциям через браузер.

В некоторых своих проектах я использовал сразу все эти инструменты. В дополнение к интерактивной версии How To Think Like a Computer Scientist есть еще интерактивная версия Think Java, подготовленная и поддерживаемая Trinket.

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

Я использовал образы виртуальных машин для некоторых курсов в прошлом, но в последнее время я чаще пользовался онлайн сервисами, как в случае с этим Jupyter-ноутбуком для книги Think DSP. А репозитории для всех моих книг подготовлены для работы с сервисом Binder.

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

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

Let's block ads! (Why?)

[Перевод] Быстрый запуск Github репозитория c Angular CLI в вашем браузере

image

На Github находится множество демок, примеров, прототипов и реальных приложений, написанных на Angular. Тем не менее, клонирование и инициализация проекта может занять много времени, что затрудняет его совместное использование и просмотр.

Именно поэтому была создана среда разработки StackBlitz, которая позволяет редактировать Angular CLI проекты в браузере. В ней сейчас пишутся примеры из официальной документации Angular.io!

Круто было бы быстро запустить любой Angular CLI проект с Github прямо в браузере, просто изменив URL-адрес?
image

Да, реально! И это делает процесс совместного использования примеров, демонстраций и приложений очень легким.

Как это работает?


Вы можете открыть любой публичный репозиторий на Github, указав имя пользователя + имя репозитория:
stackblitz.com/github/{ИМЯ_ПОЛЬЗОВАТЕЛЯ}/{РЕПОЗИТОРИЙ}

Кроме того, вы также можете указать ветку, тэг или коммит:
stackblitz.com/GitHub/{ИМЯ_ПОЛЬЗОВАТЕЛЯ}/{РЕПОЗИТОРИЙ}/tree/{ТЭГ|ВЕТКА|КОММИТ}

Загрузка за считанные секунды


Больше не нужна загрузка, клонирование или установка. Благодаря Turbo package manager StackBlitz установит все зависимости и загрузит ваше приложение за считаные секунды.

Редактирование «живого» кода в реальной среде


StackBlitz идет «из коробки» со всеми функциональными возможностями, которые есть в вашей локальной версии VS Code, например: intellisense, go to definition, hot reloading, полный доступ к npm и многое другое.

Бета-версия!


Хотелось бы услышать ваши отзывы! Сейчас этот функционал, вероятно, лучше всего подходит для небольших приложений и примеров, поскольку он еще не реализован до конца, но если вы найдете что-то, что не работает, не стесняйтесь сообщать о проблеме в Github issue, на канале Discord или в twitter @stackblitz.

Let's block ads! (Why?)

Тренинг FastTrack. «Сетевые основы». «Понимание модели OSI». Часть вторая. Эдди Мартин. Декабрь, 2012

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

Мы продолжаем цикл из 18 статей на основе его лекций:

Тренинг FastTrack. «Сетевые основы». «Понимание модели OSI». Часть первая. Эдди Мартин. Декабрь, 2012

Тренинг FastTrack. «Сетевые основы». «Понимание модели OSI». Часть вторая. Эдди Мартин. Декабрь, 2012

И вот вторая из них.

Тренинг FastTrack. «Сетевые основы». «Понимание модели OSI». Часть вторая. Эдди Мартин. Декабрь, 2012


Переходим к четвёртому уровню. Это транспортный уровень. Итак, у нас с Вами есть файл, который нужно передать. Пусть это будет тот же файл sales.ppt. Этот файл презентации PowerPoint. Мы в Cisco ужасно гордимся тем, что используем PowerPoint. И не только мы, а многим нравится использовать его.

Давайте представим, что это получасовая презентация PowerPoint на 75 слайдов, да, да, это Cisco :) И предположим, что размер файла будет составлять примерно 27 мегабайт. Мы очень часто отправляем подобного размера файлы по сети. И по сетям большие файлы никогда не отправляются одним куском, они отправляются маленькими частями.

Это как книга. Давайте сравним наш файл с книгой. Если бы я захотел отправить эту книгу по сети, я не смог бы отправить её целиком, ведь в ней так много страниц. Что мне тогда пришлось бы делать? Разбить её на главы и страницы, или ещё как-то на большее количество, после чего их можно будет отправить гораздо проще. Мне необходимо будет определить какое количество страниц я получу и придётся отрывать их по одному листу и отправлять их по-отдельности, то есть я стану расщеплять файл на мини-документы. Это называется сегментацией данных.

Таким образом на транспортном уровне, когда мы отправляем файл, начинается сегментирование данных по сети, потом они доходят до нашего сервера. Наш файл sales.ppt мы должны разбить на несколько сегментов. Но сколько глав, сколько сегментов этого файла, нам нужно отправить?

Например, я собираюсь отправить Вам по 10 глав в качестве одного сегмента файла, ну или по 20 глав. Для этого нам нужно настроить процесс. Нам нужно передать файл от одного клиента к другому. Для этого между ними нужно установить сессию и создать логический туннель связи, с одного конца к другому. И тут происходит следующее. Тот, кто запрашивает данный файл, используя протокол передачи файлов (FTP) сообщает, что файл который Вы хотите получить будет разбит на 75 частей. Получается есть 75 сегментов, которые необходимо переслать. И если он в начале как-бы скажет нам: «Эй, у меня 75 сегментов для этого файла, которые я тебе отправил», получится, что он разбил этот файл на части. И соответственно на другом конце туннеля ожидают 75 различных сегментов.

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

Итак, моё приложение решило использовать надёжный FTP. Но в чём его «надёжность» и как она обеспечивается? А обеспечивается она так. Я разделяю файл на части и отправляю первый сегмент. Когда на другой стороне сервер получает данный сегмент, то он говорит нам: «Ура, я получил первый сегмент». И отвечает: «Можешь слать мне второй». И так далее. Он получает второй сегмент и просит третий, так как он знает, что он получил уже предыдущий. Ваши приложения для работы с данными были спроектированы таким образом, чтоб использовать это, в особенности.

Все мы знаем и слышали такой термин как TCP/IP. Ну, а что означает термин TCP? TCP это протокол контроля передачи данных, который предоставляет поток данных с предварительной установкой соединения, осуществляет повторный запрос данных в случае потери данных и устраняет дублирование при получении двух копий одного пакета, гарантируя тем самым целостность передаваемых данных и уведомление отправителя о результатах передачи. К примеру, на третьем пакете происходит сбой и сервер не получает третий пакет. Он ждёт в соответствии с протоколом, и затем, спустя какое-то время ожидания, просит: «Пошли мне третий пакет снова». И если повторная передача так и не происходит, в случае нескольких подобных запросов, мы получаем «Request timout».

И что же это даёт Вашим приложениям? Надёжность, гарантию того, что файл передан успешно. Поэтому Ваши приложения для работы с данными всегда должны использовать в первую очередь TCP. Вся сеть в целом «сосёт» именно по этому протоколу. Да, это технический термин, без шуток. Я много раз слышал его от инженеров различного уровня. Именно благодаря ему Ваши базы данных в порядке.

Ну, а сколько он стоит? В жизни ведь нет ничего бесплатного. Возможно, разве что любовь моей собаки Дока. Он любит танцевать со мной вне зависимости от того, в каком я настроении. Это, пожалуй, единственно в жизни, что бесплатно. Другая собака — собака моей жены, Бэлла, не любит меня во все. Но в чём же цена тут? Это стоит нам времени и трафика, ведь нам нужно ждать ответа сервера, даже если он находится в другой части мира.

Сейчас мы нашли способ, как немного обойти механизм и немного укоротить этот процесс, благодаря функции плавающего размера окна TCP (TCP sliding window). Если произошла передача нескольких сегментов и сбоев не было, то система может сделать вывод, что сеть надёжна, и мы можем, к примеру, отправить сразу и 6 и 7 сегментов, чтобы сэкономить время. А потом мы можем также отправить сразу и 8 и 9 сегментов, так как сеть по-прежнему надёжна, и так далее. И это ускоряет передачу данных. В итоге можно заключить следующее — мы можем отправлять одновременно любое число сегментов, в зависимости от степени надёжности сети. По стандартам протокола TCP/IP, я могу отправлять сразу до 15 сегментов. Но что, если в процессе передачи сразу нескольких сегментов произойдет ошибка? Допустим я отправляю сегмент с 50 до 64, одним пакетом, и на 63 происходит ошибка. Сервер скажет — пришли мне 63 ещё разок, я его не получил. Компьютер отправит 63 и потом уже будет слать меньшее количество сегментов за раз, чтобы избежать дальнейших ошибок. Таким образом наше окно пакетной передачи данных будет иметь переменную длительность.

А теперь поговорим о другом протоколе, задействованном на уровне приложений, который Вы можете выбрать для отправки файлов по сети. Это тривиальный протокол передачи файлов — протокол TFTP (Trivial File Transfer Protocol). И если Вы посмотрите его определение, то там говорится, что он передаёт файлы по сети без надёжности. Вернёмся к нашему примеру и представим, что выбрали для передачи сегментов именно этот протокол TFTP. Как бы проходил процесс передачи? Наш компьютер сказал бы серверу: «Эй, у меня тут 75 сегментов, лови». И начал бы их сразу отправлять. Каковы преимущества этого протокола? У него быстрее скорость передачи, но где надёжность? Для своего приложения с базами данных его лучше не применять. Протокол уровня приложений TFTP основан на протоколе транспортного уровня (UDP или User Datagram Protocol) — протоколе пользовательских диаграмм. Итак, Вы можете выбрать TCP/IP или UDP/IP, в зависимости от того что Вы отправляете. Чаще всего сам уровень передачи данных выбирает нужный протокол из представленных двух.

Расскажу вам кое-что.

В 1997 году паренёк по имени Джон Чемберс, о котором Вы должно было слышали, работал президентом Cisco уже пару лет. То время было очень продуктивным в сфере сетевых технологий и Джонни хотел совершить прорыв и сделать что-то новое и полезное. Напомню, что именно Cisco придумали роутеры в начале 90-х годов, а где-то в 1993 году также придумали свитчи. Интернет зарождался и Cisco начала приобретать некоторые IT-компании, чтоб быть мировым лидером и задавать направление развитие сетей. И в 1997 году Джон Чемберс выступал здесь в кампусе перед группой инвесторов и сказал следующее:

«Наше будущее заключается в том, что все удалённые передачи станут почти бесплатными, так как они будут разделены в пакетные IP. Сети передачи голоса и данных будут объединены».

Именно в тот день и зародились основы передачи данных в Cisco. Мы стали ключом к тому, чтобы объединить разные типы данных.

В то время Интернет был далеко не у всех, а если и был, то подключение производилось через телефон. Тогда пользовательские приложения не были очень надёжными. Но отправка данных была почти также важна, как и телефонная связь. Потом очень важным стал PBX. Когда мы говорили, что сможем передавать голос по сети, люди смеялись над нами. Они говорили про Джона: «Что этот парень пил или курил? Что он вообще несёт»? Но зачем Cisco вообще было нужно объединять голосовые сети и сети данных? Да просто это могло сделать сети ещё более важными. Это заставило бы людей больше думать о возможностях сетей.

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

А теперь подумайте, какой протокол Вы бы стали использовать для передачи голосовых данных, TCP или UDP? Станет ли задержка данных для проверки надёжности проблемой при передаче голоса? Да, конечно станет. Видео и голос должны долетать до нас быстро. У нас есть до 150 миллисекунд, чтобы дать голосу долететь до Вас. Мы должны будем поддерживать скорость передачи. Мы не можем оправить слово и волноваться, что оно застрянет где-то в середине пути.

Мы не можем снова и снова его отправлять, иначе получится, что я буду говорить одно и то же, одно и то же, одно и то же. Ну Вы поняли. Поэтому нам придётся использовать протокол UDP для передачи голоса и видео. Это значит — наша сеть должна быть к этому готова. Вы должны дать сети такую способность. Вы должны подсказать сети — это голос, пусть он идёт потоком. Если параллельно идёт отправка файла и канал ограничен, нужно замедлить её, никто и не заметит, если он придёт на секунду позже. Главное поддерживать поток передачи голоса. Это критически важно, потому, что если не сделать это, то голосовой звонок или видео звонок будет убит.

Приведу пример из своего опыта. Они наняли меня, чтобы я продавал голос и видео. Тогда я продал больше голоса, чем когда-либо в истории сетей, я продал «тонны». И вот ко мне приходили клиенты и говорили, что их сеть — отстой (и это технический термин, без шуток). И я спрашиваю: «У Вас есть какие-то критические приложения по работе с данными, которые зависят от неё? — Да, конечно. — Давайте мы в начале обеспечим их функциональность, а затем займёмся задачей передачи голоса. Потому, что я не хочу иметь эффект бутылочного горлышка и затем снова возвращаться к ревизии сети».

Это и был путь Cisco. Сделать сети умными, чтобы всё это работало. В нашу эру видео эта функция очень важна. Голос не настолько велик при передаче, а вот видео уже просто огромно. Голосовой поток может быть 8 килобайт в секунду. Это очень небольшой поток в масштабах сети, но вот видео в высоком разрешении будет уже требовать более 2 мегабайт и его нужно передавать быстро. В этом и заключается важность, и Cisco знает как выполнить эту задачу.

Многие из Вас пришли из конкурирующих фирм, таких как Avaya, Nortel и т.д., все эти конкурирующие фирмы изо всех сил пытались перевести голос с PBX платформы в сеть, и знают, что там с передачей видео и голоса есть проблемы. Но мы в этом преуспели, так как предлагали готовое решение, которое может взаимодействовать с нашей сетью. Ведь как клиенты могут быть уверены в правильном взаимодействии устройства, которое просто включено в сеть, если сеть не знает о его существовании и не взаимодействует на сетевом уровне?

Раньше приходилось искать варианты в разных фирмах и если одна не могла сделать чего-то, а другая могла, то приходилось комбинировать возможности, но сейчас мы можем всё. Мы предлагаем полное обслуживание. На установление стандартов работы протоколов уходит много времени — около 24-36 месяцев, они не появляются с воздуха. Потом эти стандарты нужно загрузить в оборудование. Но мы отличаемся от конкурентов тем, что наше оборудование можно перепрограммировать. Мы разрабатываем наши чипы Asics, чтобы их можно было перепрограммировать с помощью нашего программного обеспечения. И поэтому у Вас есть возможность сегодня получить новую фичу на оборудование, которое купили полгода назад. Таким образом мы предоставляем Вам возможность получения дополнительной особенности Вашего устройства в будущем, для устройства которое Вы купили вчера. И всё это при помощи всего лишь простого обновления Вашего iOS. Так как мы в Cisco разрабатываем наше собственное программное обеспечение со своими стандартами. А нашим конкурентам придётся ждать новые чипы и новое оборудование с новыми стандартами, а на это может уйти более 2-х лет. И Вам придётся покупать полный комплект нового устройства. В этом вся и разница. Конечно наши услуги стоят дороже, но в дальнейшей перспективе это удобнее.

В современном мире технологии развиваются очень быстро, нужно уметь приспосабливаться. Мы начали говорить об IP-телефонии в 1997 году, а в 1999-2000 начали её продавать. Сейчас эти новые волны технологий накатывают всё быстрее и стремительнее. Архитектура важна как никогда с точки зрения бизнеса. Не технологий, а бизнеса.

Итак, мы говорим о передаче данных и у нас в голове есть протоколы TCP и UDP, но гораздо важнее то, что сеть может выбирать, компенсировать и понимать, какой протокол ей нужен. Голос и видео требуют использовать UDP и именно в этот момент наши конкуренты проигрывают. Даже Майкрософт предлагает кучу всего, предлагают использовать HP для соединения/переключения, использовать одно для этого, другое для того, и т.д., но в итоге, удобно ли клиенту? Я не думаю. Именно это и даёт нам преимущество. Мы предлагаем Вам целостное решение, и ведём Вас по всему пути от источника к серверу.

Давайте вспомним, кто был первым в передачи голосовых данных в 2004 году, кто был лидером в мире? Nortel Networks. Это была отличная фирма. Я никогда не ругаю конкурентов, типа Nortel, Avaya и продукцию этих компаний. Я говорю, что они иногда принимают неверные решения, точнее их руководство это делает. У меня был приятель, который работал на Nortel 18 лет. Он был прекрасным профессионалом. Но фирма не смогла предугадать требований и нужд сетей. Они не стали разрабатывать то, что разработали мы. И что же произошло с Nortel? Их больше нет, это конечно большое разочарование.

И компания Avaya. Это отличный конкурент, но и они не делают всего, что могут. Я могу Вам это гарантировать. И всё потому, что они не понимают, что сейчас важнее на рынке услуг. Сначала нужно изучить вопрос. Вы же не станете строить дом в любом месте? Вы не станете строить пятиэтажный дом на том месте, где нет хорошего фундамента?

Итак, подведём итоги по транспортному уровню. Он важен в разговоре с клиентами, когда Вы обсуждаете передачу голоса и видео. И на сегодня это важнее всего остального, так как видео «брутально». Есть отличные фирмы, разрабатывающие сети, но они держаться подальше от видео. Так как они знают, что видео сделает с ними и их сетями. Вы знаете Tandberg? Когда Tandberg обратились к IT? Tandberg были очень успешными, но они оставались в стороне от IT настолько, насколько они могли.

Но важно заглядывать в будущее. Я так и делал, меня приняли на работу и я был телекоммуникационным менеджером. И когда я приходил в офис телекоммуникационных менеджеров, то разговаривал и просто говорил о том, что нас ждёт в будущем, не только о судьбе Cisco, а в общем. Я говорил о том, сможем ли мы адаптироваться к будущему. Скоро к нам придут люди и попросят об этом. Сможем ли мы им это предложить? Мы должны быть готовы.

То же самое и о видео. Тогда мы хотели сделать видеозвонки такими же доступными, как и голосовые вызовы, но сказать проще, чем сделать. И Вы думаете IT-cпециалисты спали ночами и не переживали об этом? Переживали, причём много, потому, что боялись прийти назад и сказать: «Я не могу этого сделать». Иначе они были бы уволены. Они могли быть. Могли.

Теперь мы переходим туда, где живёт и дышит Cisco, в нашу повседневную работу, на третий уровень — сетевой уровень, который перемещаёт данные в пакетах из одной логической сети в другую. IP-адрес, маршрутизатор (роутер), DHCP. Это основное, что мы рассмотрим в этом разделе.

Вы наверное слышали историю о Cisco. Как же начиналась история Cisco? Начала её дружная супружеская пара из Stanford. К северу отсюда, в 80-х годах у них были две разные сети. И так сложилось, что муж работал в одном отделе с одним типом сети, а его жена в другом. Они не могли общаться друг с другом. И что же им оставалось делать? Как только появились персональные компьютеры PC, они приобрели такой, поставили в него порты соответствующих типов сетей и написали отличное программное обеспечение, позволившее соединить сети воедино. И теперь у них была возможность связываться, передавать информацию с одной стороны на другую, друг другу. Получается, что теперь появилась возможность соединять разные типы сетей. Именно это и делают роутеры и именно так они появились.

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

Всё это происходило в Стэнфорде и они часто виделись с людьми из UCLA и USC. Они показали им своё изобретение и спросили — Вы видели такое раньше? И у них стали просить помощи. Можно мы Вам отправим компьютер и сможете ли Вы сделать и нам такое же приспособление? И они начали поставлять эти приспособления по всем школам Калифорнии. А потом пошли уже и государственные заказы. Люди звонили и просили помочь им наладить сети в Северной Каролине, в Арканзасе, в Техасе. И наши герои поняли, что они могут на этом очень неплохо заработать. Они поняли, что получают за свою преподавательскую деятельность не так много, как могут получать от успеха в сфере сетевых технологий.

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

Но наконец, в 1985 году один человек сказал: «Знаете что, мне кажется, что это крутая идея. Но Вам нужно сделать кое-что для меня. Вы двое — умники, но Вы не сможете руководить компанией. Вы не сможете правильно продавать эти приборы. Вам нужен кто-то, кто знает, как можно продавать, специалист по маркетингу или продажам». И это был Джон Моргридж.

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

Итак, вот что делают роутеры. Соединяют разные типы сетей — это их основная функция. Сегодня мы используем роутеры в «мире голоса», как голосовые шлюзы для передачи голосовых сообщений и подключения к абонентской телефонной сети PSTN. И поэтому сегодня мы можем спокойно позвонить своему мужу или своей жене и спросить: «Дорогая / дорогой, что мне купить по дороге домой»? Всё это началось в тот момент. К сожалению, этого прибора нет в музее. Могу сказать одно, он даже не назывался роутером, его называли шлюзом.

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

Название роутер появилось уже ближе к 90-м годам. У IBM были свои роутеры, которые подключаются к мейнфрейму, у Novell свои, но сегодня у роутеров гораздо больше функций, чем когда-либо люди могли вообразить.

А теперь поговорим об IP и Ваших IP-адресах. IP расшифровывается, как Интернет-протокол. Тогда у нас было множество разных протоколов, которые мы использовали. Каждый старался придумать свой вариант и использовать его, но теперь остался лишь IP. Интернет в целом заставил всех пойти по этому пути. Этот протокол убрал с рынка многих, например Token Ring, да и ещё множество других, так как роутеры поддерживали IP. А теперь подумайте, как мы получаем свой IP-адрес?

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

Каким же образом я получаю свой IP-адрес? Ваши компьютеры знают, что где-то есть такая коробка, которая присвоит им адрес. Она динамически присваивает Вам IP-адрес, так как если Вы сами будете его указывать, он не будет актуален вне Вашего дома. Благодарить за возможность получения динамических IP-адресов нужно фирму Microsoft, как никого другого, они придумали протокол динамической настройки узла — DHCP или Dynamic Host Configuration Protocol.

У Вас в компьютерах даже есть такая настройка — получить свой IP-адрес в сети динамически. Как только Ваш компьютер подключается к сети Интернет, первое, что он делает — это кричит DHCP серверу: «Эй, мне нужен IP-адрес». И сигнал идёт в место формирования адресов. Там есть целый список из них. Определённые IP-адреса принадлежат определенной сети. На некоторое время IP-адрес сохраняется за Вами. Теперь поговорим об IP-адресах у Вас дома, дома Вы можете использовать адрес примерно, как этот — 192.168.0.4. Когда Вы покупаете беспроводное устройство или другую точку доступа, модем или DSL-модем, как много людей и устройств будет подключаться к ней? У Вас будет большая инструкция вместе с Вашим устройством, в котором будет говориться, где и как его разместить и сзади устройства будет указан порт, по которому к устройству нужно будет подключиться для его настройки. Вы подключаетесь к нему при помощи компьютера в первый раз и далее вводите адрес 192.168.0.1, который является IP-адресом приобретённого роутера по умолчанию. А потом Вы настраиваете его, подключаете к сети Интернет проводом и таким образом получаете Ваш DHCP-сервер, он сконфигурирован для этого.

IP адрес состоит как минимум из трёх частей. Это сам IP адрес, что-то вроде 192.168.0.4. Далее, маска подсети (subnet mask) в виде такого сочетания — 255.255.255.0. Третья часть — это Ваш шлюз по умолчанию (default gateway), в данном случае это Ваш роутер, потому он будет выглядеть так — 192.168.0.1.

Все эти три составляющие должны присутствовать обязательно, для того, чтобы адрес был опредёлен. И когда Вы кричите: «Эй, мне нужен IP адрес», Вы получите как минимум три эти значения. Первое значение — уникальный адрес для Вашего устройства, который присваивается роутером. Второе значение — дешифраторное кольцо, помогающее нам понять две части Вашего адреса. Первая часть это улица, на которой Вы живёте, а вторая — номер дома. То есть я живу на улице 192.168.0, в доме номер 4 в данном случае.

На моей улице может быть всего около 250 домов, столько у нас всего есть возможность подключить, не всегда нам столько нужно. У меня дома всего к сети подключено 46 IP-устройств, но я же гик, для меня это нормально. Тем не менее я не использую все. Но если мне захочется больше улиц и меньше домов, я просто заменю 255.255.255.0 на 255.255.0.0 и теперь у меня может быть уже несколько тысяч домов, но меньше улиц. Вот так вот Вы получаете свой IP-адрес.

В данный момент это особенно важно, так как это основа мобильности. Кто из нас не любит мобильность. Мы все её любим. Это обычная сеть. Конечно же хорошо иметь 3G или 4G. Но Вы знаете, чем мне нравится сеть Cisco? Она быстрее, несмотря на то, что она 3G. Сейчас у меня на столе лежат телефон, ноутбук и все они подключены к беспроводной сети. И внутри моих устройств есть несколько сетевых адаптеров (NIC). Вся эта сеть кажется магией. И мы хотим, чтобы наши клиенты так думали. Мы хотим быть для них очень прозрачными. Но на самом деле это очень сложные процессы. Нам нужно объяснить клиентам, что мы научились делать свою работу так, чтобы всё выглядело просто, но это не делает нашу работу простой.

Сегодня у нас как никогда много разных девайсов и все они подключены к сети. Мобильность приобретает новую форму, теперь, если Вы хотите использовать видео на телефоне, компьютере и iPad — Вы можете это сделать, для этого не потребуется отдельная сеть. Вам не нужно будет подключаться к проводной сети сейчас. У каждого прибора может теперь быть свой адрес, три разных адреса на Ваших трёх устройствах, сеть стала достаточно умной для того, чтоб определить тип устройства и приложений, которые там используются, стоит ли подключать его к сети и будет ли это безопасно. Возможно я не буду передавать поток видео в качестве 1080p на свой мобильный, так как это вероятно будет неэффективным, но вот для iPad это уже имеет смысл. И я смогу сделать это, так как мы добавили дополнительный уровень интеллекта в сеть.

Давайте поговорим о том, как работает концепция BYOD (Bring Your Own Device). Все говорят о ней. Почему она так важна? Она может основываться на устройстве, может быть основана на приложении, ну и может основываться на разных других вещах. Но есть и ещё одна важность концепции BYOD.

Приведу в пример Эмили, она старшая из моих дочерей, и она не очень переживает из-за своих оценок. Она очень разносторонняя девочка и может найти контакт с любым человеком. Это делает её социально активной. Она может прийти сюда и наладить отношения с Вами очень быстро. Она очень классная, но вообще никогда не думает об отметках в школе. Сейчас она переходит в 6 класс. И у меня есть телефон HTC EVO. Она тоже захотела телефон и я купил ей самый уродливый из всех, один из тех телефонов TracFone, за которые Вы оплачиваете только время разговоров. Вы платите только за минуты общения. И я дал ей этот телефон и предупредил её, чтобы она пользовалась им только в случае необходимости. Я дал ей 800 минут, она может мне позвонить в любой момент и откуда угодно. Но сам телефон не был, так сказать, крутым. На это она мне сказала: «Папа, я хочу такой телефон, как у тебя». И я поставил ей условие. Если ты получишь все пятерки в следующем году во всех четвертях, я куплю тебе любой телефон. Мы пойдём в магазин Sprint, а я использую их, и ты сможешь выбрать то, что захочешь, но сначала закончи год с пятерками.

Я был уверен, что у неё не получится, но она начала получать одни пятерки в четвертях, но в последней четверти получила 4 по математике. Моя жена посмотрела на меня и сказала, что я буду самым последним ослом в округе, если не куплю дочке телефон и передо мной встал серьезный выбор, но я не собирался сдаваться.

И тут мы пошли на выпускной её класса и там помимо неё было еще 127 человек. Там началось вручение особых призов, вроде приза за посещаемость, чего я никогда не понимал, зачем ходить в школу каждый день? Поболей денёк :). И так далее. И вот наступает время последней номинации — ученик года. Эта номинация подразумевает не только оценки, но и общее отношение человека. Активность, участие в мероприятиях, отношения с людьми, в общем всё вместе. И моя дочка получает эту премию. Моя дочь идёт на сцену получать премию и жена смотрит на меня и говорит: «Конечно, это ведь самая простая вещь, которую можно сделать в жизни». Она возвращается со сцены и я говорю, что я знаю, что она получила четвёрку, но так как она заслужила премию, мы пойдём в магазин Sprint и купим ей такой же телефон, как у меня. Мы его купили. И тут я смотрю на счёт за телефон через месяц. Я вижу две цифры — 5279 и 29. Как Вы думаете, что это за цифры? Это количество отправленных смс и минут разговоров соответственно, оставалось 3 дня до конца месяца. Хорошо, что у неё безлимитные смс. Но 25 из этих 29 минут были звонками ко мне, так как она и мне часто пишет, но я всегда отвечаю всего 2 слова: «Перезвони мне». Потому, что люди обычно тратят кучу времени на всё это.

Итак, возвращаясь к нашей теме — BYOD. Как Вы думаете, можно ли у Эмили забрать то, что Вы ей дали? Захочет ли новое поколение пользоваться чужими девайсами? Нет. Это мы с Вами раньше радовались любому телефону. Я был рад если бы мне подарили простой PC. Я был бы рад получить эмулятор терминала 3270, или какой-либо телефон. И я был бы крайне доволен, даже более чем. Но сейчас новое поколение стало выбирать. Они могут пользоваться своими приборами. И вот BYOD — это новое поколение. BYOD важен и мобильность является ключевой частью этого. Представим, что я Ваш работодатель и я могу купить Вам компьютер или позволить Вам работать на Вашем личном, за который мне не придётся платить.

С другой стороны многие противятся этой концепции, но её уже не остановить. С появлением беспроводной связи это уже не остановить. Теперь самое главное в работе это гибкость. Это не рабочие часы и не рабочие дни. Если раньше Вам нужно было сидеть на работе от звонка до звонка, в буквальном смысле, то теперь Вы не сможете людей заставить работать в таких жестких рамках. Когда я пошел в Blue Cross и Blue Shield, я был управляющим по операциям голосовых данных. И впервые когда я пошел туда, в 1995-ом, звучали звонки в 9 часов утра и в 5 часов вечера. Это было, как в школе. Сейчас всем нужна гибкость. Многие работают и вне рабочего пространства. Я часто присутствую на конференц-связи, даже находясь на футбольном поле. «Эй, извини дорогой, я вижу, что ты играешь в футбол, но мне нужно отойти и решить вопрос по бизнесу. Я уже здесь, что я пропустила?». Вот как примерно это работает. Я понимаю, что это моя работа и мне приходится это делать. И так сейчас везде. Не только в Cisco, хотя мы и здесь, как и во многом другом, остаемся лидерами. Двери открылись в тот момент, когда кто-то из начальства принёс на работу свой iPad. Всё, процесс запущен, никто не мог им это запретить.

Продолжим изучать модель OSI, мы почти подошли к концу и сейчас нас ждёт второй уровень. Мы уже говорили с Вами о пакетах и когда Вы где-либо услышите слово пакет, Вы будете думать о третьем уровне. Кроме того, ранее мы говорили о данных и о том, как мы разбиваем их на сегменты, это происходило на четвёртом уровне, затем мы говорили о том, как мы берём отдельный сегмент и разбиваем его на маленькие необходимые кусочки. И всё это потом мы собираем в пакет. Теперь давайте получше разберемся в том, что такое пакет.

Пакет — это что-то вроде конверта. Когда мы отправляем конверт по почте, что мы на нём пишем? Конечно же адрес получателя, кому мы отправляем. И здесь мы тоже будем писать адрес, и это будет снова логический адрес. Это уже определено в программном обеспечении и поэтому всё это происходит внутри Вашей операционной системы. Не важно какой из них Вы пользуетесь, будет это Windows, Apple или Linux, все они получают для себя IP-адрес для соединения по сети. Итак, мы берём книгу, которую нужно отправить. Разбиваем её на несколько маленьких глав, которые мы называем сегментами, так как в пакет может поместиться только определённое количество информации — страниц. И потом мы берём эти отдельные страницы сегмента по одной. Получается что-то вроде: глава 2, страница 3, глава 2, страница 4, и так далее. Мы помещаем эти страницы в наш пакет (конверт) и пишем IP-адрес, который является местом назначения.

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

На канальном уровне данных у нас есть пакет данных, который к нам поступает и у которого есть IP-адрес источника и пункта назначения. И мы должны теперь создать какой-то интерфейс для физического подключения. Это может быть беспроводная сеть (Wireless), которая использует радио волны или проводное подключение, не важно. Это уже не просто связь между двумя логическими сетями, а связь между двумя устройствами. Как же нам это сделать?

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

Давайте возьмем ноутбук. Когда он подключен к сети, то у него есть IP-адрес, в нём есть сетевой интерфейс, сетевая карта. У неё есть MAC-адрес, кроме того у него есть возможность подключаться по WiFi и MAC-адрес для карты доступа к беспроводной сети передачи данных. Но в ноутбуке также есть и Bluetooth, на всякий случай, совсем другой тип сети. А это означает, что есть еще и MAC-адрес для Bluetooth-устройства. В общем у этого ноутбука полно MAC-адресов. Но если мой IP-адрес поменяется, поменяется ли MAC-адрес? Нет. Вы можете подключиться к нашей сети и получить логический IP-адрес, который может быть другим, но ваш MAC-адрес не изменится и останется тем же самым. Потом Вы придёте в отель и подключитесь к другой сети и Ваш IP-адрес снова поменяется, но MAC останется прежним. Вы носите этот MAC-адрес с собой куда бы Вы не пошли. Итак, мы помещаем пакет в другой конверт и переносим от одного устройства к другому, тут к делу подключается свитч, но мы подробно поговорим о свитчах в следующий раз.

А пока я Вам немного расскажу про основы переключения в сегментированный формат. Обычно свитчи обитают на втором уровне. Они смотрят на MAC-адреса, так как они умные. Свитчи вообще являются первым сетевым устройством, где можно манипулировать настройками и потому они определяют общий интеллект всей сети. Чем умнее свитч, тем умнее сеть.

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

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

Первый компьютер знает о целостности данных, и мы хотим их передать в таком же целостном виде. Именно для проверки надёжности передачи данных у нас есть FCS (Frame Check Sequence) — последовательная проверка кадров. Некоторые называют это CRC (Cyclic Redundancy Check) — циклическая проверка чётности с избыточностью. И всё это – формула.

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

Расскажу еще подробнее. Мой компьютер превращает данные в нули и единицы и передаёт их по сети всем другим устройствам, которые понимают этот принцип. Первым устройством на пути оказывается свитч, работающий на втором уровне, и который из полученных данных по формуле получает то же значение, что было изначально, к примеру 316. Он сравнивает эти значения и если они сходятся, отправляет данные дальше. Но что будет, если свитч насчитает 326, а не 316? Свитч поймёт, что по пути к нему во время передачи данных по кабелю, как правило, медному, cat5, что-то пошло не так. Большая часть ошибок происходит именно на этом физическом уровне, так как часто у нас плохие кабели или старое оборудование и так далее. И это называется ошибка фрагментации данных, потому что целостность данных не правильна.

Итак, свитч получил неверную информацию и он это понимает. Он говорит себе — это не те данные, они не целостны и не передаёт их. Что в итоге происходит с Вашими данными? На транспортном уровне принимающий компьютер не получает все данные. Он даёт сигнал о том, что нужно повторить попытку. Но это в случае, если у Вас используется TCP протокол на уровне приложений. Если же у вас UDP протокол, данные продолжают поступать в неправильном виде. Именно на этом уровне, на втором уровне, в модели OSI, мы проверяем ошибки. Только здесь. Большая часть проблем будет связана с плохим состоянием кабеля, но тем не менее.

Я помню, когда были разные типы Ethernet-сетей, я был в офисе и в офис пришла сотрудница, которая получила штраф за превышение скорости. Она бросила сумку под свой стол и пыталась подключиться к беспроводной сети, но у неё это не получалось и она постоянно жаловалась, что сеть медленная. Я провёл проверку и оказалось, что у них в офисе был плохой кабель. Но даже если у Вас беспроводная сеть, всё равно появляются ошибки. Так как это единственное место во всей модели OSI, где мы можем осуществить такую проверку на ошибки. И этот свитч, несмотря на то, что он может осуществлять подсчёт, не сообщает о том, что он что-то «выбросил» и пакет нужно передать повторно. Так как это находится на более высоком уровне, уровне приложений, на котором мы и определяем, что если это передача голоса при помощи IP-телефонии, то какое-то солово или часть не будут пересланы повторно, мы получим прерывание, так как будет слишком поздно. То же самое и с видео. Но если это приложение базы данных, то нам будет необходимо повторить передачу данных, так как мы хотим, чтобы эти дроби оказались в нужном месте. Свитчи это очень и очень важная часть портфолио Cisco. И Cisco ставит большое ударение на интеллектуальность этих устройств. Мы поговорим в дальнейшем ещё об этом.

Вернёмся к первому уровню, который является просто физическим уровнем. Физический уровень — это уровень медных проводов, оптических кабелей, радиоволн и так далее. Когда мы говорим о Wireless LAN, то мы говорим о комбинации первого и второго уровней. Они используют радиоволны, чтобы соединить Вас с нужной точкой. Точке доступа нужен будет Ваш MAC-адрес, который находится в Ваших сетевых картах (NIC). Изначально мы использовали медный кабель, но потом перешли на оптоволоконный кабель, почему? Каковы преимущества оптоволоконного кабеля над медным? Расстояние работы, скорость. Но нельзя сказать, что Gigabit Ethernet быстрее с медным кабелем, чем с оптоволоконным, это не так. Это только определяет скорость, которую мы можем получить, применив кабель.

По сути оптоволоконный кабель — стеклянная трубка. Мы конвертируем нули и единицы в световые волны. Я могу передать 10 гигабитный сигнал по такому кабелю и мне понадобится одна световая волна, одной длины, одного цвета. Параллельно с этой волной может идти вторая световая волна и они не будут друг другу мешать, интерферировать. Мы всё ещё не знаем до конца, какова максимальная ёмкость оптоволоконного кабеля, так что продолжаем её изучать.

CISCO производит свитчи, способные передавать данные по определённому типу оптического кабеля на расстояние до 60 миль (100 километров). Более подробно мы об этом расскажем Вам позже.

Теперь, когда мы говорим о радиоволнах и беспроводной сети, мы всегда вспоминаем о BYOD и о мобильной стратегии, которая есть у нас для наших клиентов. Люди не хотят быть привязаны. Вы же не станете подключать свой iPad к Вашему Ethernet-свитчу. Поэтому мы понимаем, что беспроводная связь будет становиться всё важнее и важнее со временем для наших клиентов. Мы будем расширять возможности беспроводных систем в ближайшем будущем.

Многие из Вас спрашивали о том, какие материалы можно почитать по этой теме. Я не рекламирую книгу, мне за это не платили, но знаю этого автора и виделся с ним. Это хорошая книга «Cisco Networking Simplified» и я потратил бы гораздо больше бы времени, чтоб написать тоже самое. Если мы заполним эту аудиторию умными людьми, конечно же, я окажусь где-то в конце. И этот автор, на мой взгляд, очень просто и доступно объясняет принцип работы наших сетей. Это отличная книга для начала. Вы забудете многое и Вам запомнится может процентов 30 из того, что мы обсуждали, но книга поможет Вам это вспомнить. В ней есть акронимы для запоминания модели OSI. К примеру, APSTNDP.

APSTNDP можно расшифровать, как:

All People Seem To Need Data Processing – Все Люди Кажется Нуждаются в Обработке Данных.

Или есть еще один обратный:

Please Do Not Throw Sausage Pizza Away – Пожалуйста не Выбрасывайте Пиццу с Сосисками.

Или вот еще:

Please Do Not Tell Sales People Anything — Пожалуйста Не Говорите Продавцам Ничего (конечно же это версия SC).

В заключение – это именно та структура, по которой всё будет проходить.

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

Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас оформив заказ или порекомендовав знакомым, 30% скидка для пользователей Хабра на уникальный аналог entry-level серверов, который был придуман нами для Вас:Вся правда о VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps от $20 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле? Только у нас 2 х Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 ТВ от $249 в Нидерландах и США! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?

Let's block ads! (Why?)