Comments 68
*шутка про скорость передачи грузовика с жесткими дисками*
Но в целом скорости конечно поражают, еще бы оборудование под них было доступным и понятным… А бюджетным оно явно не скоро станет.
Но в целом скорости конечно поражают, еще бы оборудование под них было доступным и понятным… А бюджетным оно явно не скоро станет.
На данный момент в магистральных сетях большой дальности выявляется тенденция, что уже дешевле строить по новой технологи (другое решение в дизайне усиления, компенсаций дисперсии в сумме уменьшают суммарную стоимость проекта), а стоимость оборудования все продолжает снижаться. Так что это вопрос времени, причем не очень большого.
Для передачи больших объемов данных частным лицам или небольшим коммерческим предприятиям, действительно проще отправить курьера с носителем. Когда же мы говорим о больших передачах данных, например, между дата центрами, этот вариант не пройдет :)
Цитата:
Эта идея не нова, ее часто называют СникерНетом, именно так Google передает большие объемы данных внутри своей компании.
Питер Джексон в одном из видео рассказывал, как парень из съемочной группы однажды понес пешком по городу айпод с чуть ли не всеми отснятыми материалами LOTR, а на на полдороге напали грабители, позарившись на айпод.
Убежал, спас фильм :)
Убежал, спас фильм :)
UFO just landed and posted this here
позарились небось на айпод, а нёс парень сумку с хардами, забитыми каким-нибудь MJPEG2000.
Не-не, они текущие материалы так носили.
текущие материалы — само собой! айпод классик грех было не использовать в качестве переносного винта в 2003м году. упоминались-то «чуть ли не все отснятые материалы».
UFO just landed and posted this here
Там несколько съемочных площадок, на которых одновременно шла работа, и иногда быстрее всего скинуть материал, который должен режиссер посмотреть и «дать добро» на какой-то переносной диск. Речь не шла обо всех материалах и обо всем фильме, но о какой-то значительной его части, как я помню.
Когда мы говорим о передаче между дата центрами 1ПБ данных, грузовик снова врывается в тредик :)
А если пару петабайт надо гонять постоянно между континентами? На керосине разоришься :)
Все эти грузовик-нет почему-то не учитывают скорость записи на эти самые винты/диски и скорость считывания.
А как именно вы хотите её учитывать?
1 петабайт — это минимум 500 SATA дисков обычно в полках по 24 диска, каждая полка подключена к отдельному серверу. 4 диска легко забивают 1 гигабит при линейном чтении или записи. И когда идёт разговор о переносе 1 петабайта данных в другой ДЦ — чаще всего это означает, что надо не копию сделать, а именно перенести данные, дабы освободить место в старом ДЦ или перераспределить нагрузку.
Из моего опыта, узкое место при подобных операциях — именно сеть, гигабитный интерфейс машинки и 10-гигабитные меж-ДЦ линки. При нормальной работе сервиса этих показателей вполне достаточно, но вот если хочется БЫСТРО перетащить подобные объёмы данных — грузовик рулит. Это — практика, коллеги так делали :)
1 петабайт — это минимум 500 SATA дисков обычно в полках по 24 диска, каждая полка подключена к отдельному серверу. 4 диска легко забивают 1 гигабит при линейном чтении или записи. И когда идёт разговор о переносе 1 петабайта данных в другой ДЦ — чаще всего это означает, что надо не копию сделать, а именно перенести данные, дабы освободить место в старом ДЦ или перераспределить нагрузку.
Из моего опыта, узкое место при подобных операциях — именно сеть, гигабитный интерфейс машинки и 10-гигабитные меж-ДЦ линки. При нормальной работе сервиса этих показателей вполне достаточно, но вот если хочется БЫСТРО перетащить подобные объёмы данных — грузовик рулит. Это — практика, коллеги так делали :)
Растягивается сеть между ДЦ (во втором ДЦ становится видна сеть первого ДЦ, маршрутизация это или просто растягивание L2 уже не важно), и начинается миграция данных возможно даже без перерыва предоставления сервиса. Все довольны. Кроме водителя грузовика, он остался без работы.
И еще… Вы упомянули перенос, а не копию. Это какой же надо иметь мозг, что бы решится перевезти полный грузовик ЖИВЫХ данных без их копии… Один шахид на маршрутке и все… бизнес данного ДЦ можно закрывать…
И еще… Вы упомянули перенос, а не копию. Это какой же надо иметь мозг, что бы решится перевезти полный грузовик ЖИВЫХ данных без их копии… Один шахид на маршрутке и все… бизнес данного ДЦ можно закрывать…
Вопрос в другом. Сколько времени займет такая миграция по сети?
Если у нас 10G между ЦОДами в соседних комнатах, то перекачивать данные на такой скорости не проблема, но если ЦОДы в разных городах, то получить ~10G полезной скорости становится задачей нетривиальной. Вот и получается в результате, что записать диски (ленты) и перевести их на другую площадку грузовиком или самолетом может оказаться быстрее, даже в случае если это репликация.
Если у нас 10G между ЦОДами в соседних комнатах, то перекачивать данные на такой скорости не проблема, но если ЦОДы в разных городах, то получить ~10G полезной скорости становится задачей нетривиальной. Вот и получается в результате, что записать диски (ленты) и перевести их на другую площадку грузовиком или самолетом может оказаться быстрее, даже в случае если это репликация.
На самом деле задача совсем не сложная, многополосная передача дает 95-98% полезной скоростиэ
Но и совсем не простая.
Во первых мало что из коробки умеет так делать, во вторых такая сегментация данных иногда нежелательна, а иногда и невозможна, но самая большая проблема в том, что неэффективность нарастает с ростом расстояния(все проблемы от скорости света) и в результате многополосная передача может перестать давать тот-же эффект из-за взаимовлияния потоков друг на друга.
По этому сейчас вполне развиваются оба направления и то, как передавать данные параллельно и то, как увеличить эффективность передачи в каждом соединении.
Во первых мало что из коробки умеет так делать, во вторых такая сегментация данных иногда нежелательна, а иногда и невозможна, но самая большая проблема в том, что неэффективность нарастает с ростом расстояния(все проблемы от скорости света) и в результате многополосная передача может перестать давать тот-же эффект из-за взаимовлияния потоков друг на друга.
По этому сейчас вполне развиваются оба направления и то, как передавать данные параллельно и то, как увеличить эффективность передачи в каждом соединении.
Простите, но какой же надо иметь мозг, чтобы хотя бы подумать о том, чтобы хранить 1ПБ данных в одной копии? Конечно же, данные живые, и конечно же перенос, но есть ещё как минимум 1 копия (а лучше две) в других датацентрах. Писать данные сразу в 3 копиях обычно не такая большая проблема, как перенести одну из копий.
На досуге, посчитайте, сколько времени придётся переливать через 10G канал 1 петабайт данных, причём только по ночам. Через несколько лет скорость каналов увеличится на порядок, и объёмы данных увеличатся на порядок, время переноса полной копии же изменится слабо.
На досуге, посчитайте, сколько времени придётся переливать через 10G канал 1 петабайт данных, причём только по ночам. Через несколько лет скорость каналов увеличится на порядок, и объёмы данных увеличатся на порядок, время переноса полной копии же изменится слабо.
При наличии живой копии (а если и не одной) это и не проблема вовсе.
Но кто по вашему живые копии хранит в двух ДЦ? Даже амазон так не делает, только за дополнительные деньги.
Я сталкивался с переездами ДЦ на грузовике когда ОДНА копия и она живая.
Да была система бекапа (и то уже что то), но вы попробуйте тот петабайт из бекапа поднять, за месяц может поднимется )
Но кто по вашему живые копии хранит в двух ДЦ? Даже амазон так не делает, только за дополнительные деньги.
Я сталкивался с переездами ДЦ на грузовике когда ОДНА копия и она живая.
Да была система бекапа (и то уже что то), но вы попробуйте тот петабайт из бекапа поднять, за месяц может поднимется )
Вы смешной такой, типичный диванный теоретик. Свои данные Амазон хранит в разных ДЦ. Яндекс хранит свои данные в разных ДЦ. Да любая компания, которая хочет работать при потере одного ДЦ (а это случается не так уж и редко, Амазон тому пример). И процесс перевоза данных, который растягивается на месяцы — это большая проблема.
Бекап и 1 петабайт данных — уже смешно. Как вы предлагаете это осуществить? Гугл просто держит 3 копии. Амазон в своём S3 тоже три копии. Яндекс тоже старается в 3 копиях.
Бекап и 1 петабайт данных — уже смешно. Как вы предлагаете это осуществить? Гугл просто держит 3 копии. Амазон в своём S3 тоже три копии. Яндекс тоже старается в 3 копиях.
Уважаемый, мы не переходили на личности. Я не теоретик, я практик, и практика моя очень обширна в данных вопросах. А в вашей компетентности у меня большие сомнения.
Амазон в нескольких ДЦ? И именно бесплатно (без дополнительных денег)??? Пруф в студию…
S3 этого не делает.
Совет на будущее… прежде чем разбрасываться высказываниями вникните в суть проблемы… а не выдавайте ответы на основе того что вы «где то слышали».
Амазон в нескольких ДЦ? И именно бесплатно (без дополнительных денег)??? Пруф в студию…
S3 этого не делает.
Совет на будущее… прежде чем разбрасываться высказываниями вникните в суть проблемы… а не выдавайте ответы на основе того что вы «где то слышали».
Amazon S3 redundantly stores your objects on multiple devices across multiple facilities in an Amazon S3 Region.из этого утверждения это не значит 2 дата центра разнесенных на большое расстояние друг от друга, это может значить отдельный машинный зал (возможно со своими отдельными инфраструктурными системами). Но когда ложится один ДЦ полностью, как показывает опыт у амазона данные не доступны.
В это сложно поверить, но Амазон — это далеко не только облачные сервис. Это в первую очередь сервисы для своих внутренних нужд и что-то мне подсказывает, что для себя они и кроссдатацентровую репликацию используют и много чего еще, что для внешних клиентов только за отдельные деньги продается.
Прошу прощения за нескромный вопрос, но, например?
Я не теоретик, я практик, и практика моя очень обширна в данных вопросах.
Прошу прощения за нескромный вопрос, но, например?
Что ж, извините, если задел.
Amazon AWS — это сервисы, которые были разработаны изначально для работы самой компании, но потом стали продаваться наружу. Почти каждый из них изначально был сделан именно для внутренних нужд: понадобилась аналитика для рекламы — научились поднимать Hadoop — сделали Elastic MapReduce. Аналогично, построили несколько ДЦ, в которых есть S3 — научились записывать данные в разные ДЦ для увеличения доступности площадки amazon.com — стали продавать за деньги. Если кто-то не хочет покупать эту услугу за дополнительные деньги (а аренда каналов между ДЦ не бесплатная), то он сам себе злобный буратино. Почему это должно быть бесплатно? Почему вы считаете, что свои данные Амазон хранит в одном ДЦ?
Совет про вникание в суть неплохой, прислушайтесь к нему и сами :) В контексте тредика (напомню, 1 петабайт данных) вы делали следующие высказывания и предположения: 1 копия данных, бэкап, несколько месяцев переливки данных это не проблема, никто не хранит живые копии в нескольких ДЦ.
Чтобы развеять ваши сомнения — я, внезапно, занимаюсь разработкой хранилища данных в Яндексе, с объёмами пользовательских данных порядка петабайтов. И я, как мне кажется, несколько в курсе проблем, упомянутых в тредике.
Очень жду вашего ответа с рассказом о вашем опыте в сфере хранения больших объёмов данных. Ещё раз прошу прощения за диванного теоретика.
Amazon AWS — это сервисы, которые были разработаны изначально для работы самой компании, но потом стали продаваться наружу. Почти каждый из них изначально был сделан именно для внутренних нужд: понадобилась аналитика для рекламы — научились поднимать Hadoop — сделали Elastic MapReduce. Аналогично, построили несколько ДЦ, в которых есть S3 — научились записывать данные в разные ДЦ для увеличения доступности площадки amazon.com — стали продавать за деньги. Если кто-то не хочет покупать эту услугу за дополнительные деньги (а аренда каналов между ДЦ не бесплатная), то он сам себе злобный буратино. Почему это должно быть бесплатно? Почему вы считаете, что свои данные Амазон хранит в одном ДЦ?
Совет про вникание в суть неплохой, прислушайтесь к нему и сами :) В контексте тредика (напомню, 1 петабайт данных) вы делали следующие высказывания и предположения: 1 копия данных, бэкап, несколько месяцев переливки данных это не проблема, никто не хранит живые копии в нескольких ДЦ.
Чтобы развеять ваши сомнения — я, внезапно, занимаюсь разработкой хранилища данных в Яндексе, с объёмами пользовательских данных порядка петабайтов. И я, как мне кажется, несколько в курсе проблем, упомянутых в тредике.
Очень жду вашего ответа с рассказом о вашем опыте в сфере хранения больших объёмов данных. Ещё раз прошу прощения за диванного теоретика.
Про диванного теоретика принято )
Ну если «внезапно, занимаюсь разработкой хранилища данных в Яндексе» это интересно. Какой то определенный сервис? Ведь я подозреваю требования к стораджу явно отличаются от типа сервисов.
По моему опыту если очень кратко, то опыт проектирование и строительства нескольких ЦОД с нуля, уровнь tier3 по TIA. Система оптических колец по Москве между 4-мя ДЦ. По стораджам Метрокластер, Active/Active хранилище на базе 2-х ЦОД, синхронная и асинхронная репликация, всё это на FC и iSCSI, хотя было и еще немного на NFS. Профиль данных критический к потере и простою (не нарисованный, реальный SLA >99,9), внутренние данные разных компаний. Ну как то так если коротко )
Ну если «внезапно, занимаюсь разработкой хранилища данных в Яндексе» это интересно. Какой то определенный сервис? Ведь я подозреваю требования к стораджу явно отличаются от типа сервисов.
По моему опыту если очень кратко, то опыт проектирование и строительства нескольких ЦОД с нуля, уровнь tier3 по TIA. Система оптических колец по Москве между 4-мя ДЦ. По стораджам Метрокластер, Active/Active хранилище на базе 2-х ЦОД, синхронная и асинхронная репликация, всё это на FC и iSCSI, хотя было и еще немного на NFS. Профиль данных критический к потере и простою (не нарисованный, реальный SLA >99,9), внутренние данные разных компаний. Ну как то так если коротко )
Мы стараемся делать более общее решение, а сервисы уже используют его слегка по-разному. Если UGC — то 3 копии в 3 разных ДЦ, сервис может полноценно работать даже при потере одного ДЦ. Большинство хочет хранить много данных, и производительность лимитируется диском. Для внутренних нужд сервисов применяются и другие конфигурации. Недавно прикидывали производительность при чтении/записи в память селких ключей (эдакий аналог memcache) — получилось больше 200 тысяч запросов в секунду обрабатывать на одной машине, 8 ядер из настоящих 16 были в sys :) Это как раз вариант, когда надо хранить мало данных, но очень быстро их в реалтайме обрабатывать, агрегировать и изредка скидывать на диск.
Из сильных отличий от всяких метрокластеров — работа с объектами, а не с блочными устройствами. Существенно упрощается синхронизация записей, можем делать какую-то работу на стороне хранилища, да хоть MapReduce организовать по данным. Ну и полностью горизонтальное масштабирование, чего совсем нет у NetApp и прочих производителей хранилищ с FC/iSCSI/AoE интерфейсами, которые предоставляют именно блочные устройства. Причём масштабирование как по объёму, так и по количеству клиентов — нет никаких ограничений, сколько машин работают с данными клиентов, каждый объект блокируется независимо от остальных. Но какой нибудь Оракл уже не запустишь, факт.
Кстати, фейсбук, оказывается, именно от NetApp и отказался, когда перешёл на самопальное хранилище haystack: www.niallkennedy.com/blog/2009/04/facebook-haystack.html
Из сильных отличий от всяких метрокластеров — работа с объектами, а не с блочными устройствами. Существенно упрощается синхронизация записей, можем делать какую-то работу на стороне хранилища, да хоть MapReduce организовать по данным. Ну и полностью горизонтальное масштабирование, чего совсем нет у NetApp и прочих производителей хранилищ с FC/iSCSI/AoE интерфейсами, которые предоставляют именно блочные устройства. Причём масштабирование как по объёму, так и по количеству клиентов — нет никаких ограничений, сколько машин работают с данными клиентов, каждый объект блокируется независимо от остальных. Но какой нибудь Оракл уже не запустишь, факт.
Кстати, фейсбук, оказывается, именно от NetApp и отказался, когда перешёл на самопальное хранилище haystack: www.niallkennedy.com/blog/2009/04/facebook-haystack.html
У NetApp коли мы о нем ) Появился режим Cluster-Mode это как раз то что может параллелится хорошо. 26 систем (по 2 контроллера каждая) на NFS, и 6 систем на блочных протоколах iSCSI и FC.
Тема хорошая как раз для BigData. Стоимость конечно не сахар… но зато «почти из коробки».
Если бы тогда это у неттапа было не в стадии глухой беты (раньше у них это называлось OoTap GX) то глядишь и facebook бы не свалил.
Но как говорится хороша ложка к обеду )
Тема хорошая как раз для BigData. Стоимость конечно не сахар… но зато «почти из коробки».
Если бы тогда это у неттапа было не в стадии глухой беты (раньше у них это называлось OoTap GX) то глядишь и facebook бы не свалил.
Но как говорится хороша ложка к обеду )
Максимум 900 метров между нодами, на сколько я понял, маловато будет :) К тому же, 26 систем — это уже ограничение сверху, около 50 петабайт суммарно, да? Мне кажется, сейчас у фейсбука уже больше фоточек.
И это всё же не про BigData. BigData — это, прежде всего, возможность локального выполнения операций над данными. Когда это свойство теряется — Map из MapReduce становится сильно накладнее, и в итоге время обработки данных вырастет. Ну и, опять же, линейное наращивание мощностей — воткнул ещё сотню серверов с полками дисков и вперёд.
Кстати, с большим удовольствием посмотрел бы, как у NetApp сделана консолька администратора системы — наверняка же там как-то рисуется, где что поломалось, какой диск надо поменять и т.д. Если хотите — можно как нибудь встретиться, я порассказываю, как у нас хранилище устроено и как решаются основные проблемы.
И это всё же не про BigData. BigData — это, прежде всего, возможность локального выполнения операций над данными. Когда это свойство теряется — Map из MapReduce становится сильно накладнее, и в итоге время обработки данных вырастет. Ну и, опять же, линейное наращивание мощностей — воткнул ещё сотню серверов с полками дисков и вперёд.
Кстати, с большим удовольствием посмотрел бы, как у NetApp сделана консолька администратора системы — наверняка же там как-то рисуется, где что поломалось, какой диск надо поменять и т.д. Если хотите — можно как нибудь встретиться, я порассказываю, как у нас хранилище устроено и как решаются основные проблемы.
Да, все верно ограничения такие есть. Со временем обещают убрать, тогда да будет интереснее.
Да, линейное наращивание это конечно здорово, но для блочного доступа (применительно к большим нагрузкам, преимущественно случайным) нормальных вариантов (цена, надежность, производительность, гибкость, масштабируемость) особо и нет.
А то что заявляется как таковое, если оно как программное решение (то есть может ставится на свою конфигурацию-сервер) по сути имеют кучу проблем (как например: IBM GFS, Gluster и т.д. ). Так что то же NetApp позволяет хотя бы спать спокойно )
По поводу выхода диска на нетапп вообще прикольная тема, он сам отправляет репорт производителю и автоматически заказывает новый диск, который привозят на следующий день. Вообще без человеческого участия, только расписаться при получении )
Да, линейное наращивание это конечно здорово, но для блочного доступа (применительно к большим нагрузкам, преимущественно случайным) нормальных вариантов (цена, надежность, производительность, гибкость, масштабируемость) особо и нет.
А то что заявляется как таковое, если оно как программное решение (то есть может ставится на свою конфигурацию-сервер) по сути имеют кучу проблем (как например: IBM GFS, Gluster и т.д. ). Так что то же NetApp позволяет хотя бы спать спокойно )
По поводу выхода диска на нетапп вообще прикольная тема, он сам отправляет репорт производителю и автоматически заказывает новый диск, который привозят на следующий день. Вообще без человеческого участия, только расписаться при получении )
Так в том то и дело, что для BigData в том понимании, в котором оно есть в гугле/фб/амазоне/etc, блочные устройства не нужны и даже неудобны. Хотя бы тем, что блочное устройство не прицепишь одновременно к нескольким машинкам. Не локально, опять же. Если интересно — почитайте про HDFS и Google File System и Google Bigtable, там как раз хорошо описан подход к хранению и горизонтальному масштабированию.
Я думаю что при переносе между дата-центрами, перетащить БЫСТРО — не такой важный критерий по сравнению с перетащить НЕ ЗАГРУЖАЯ КАНАЛЫ. Для чуваков, у которых предоставление каналов — это основная форма заработка (наряду с предоставлением вычислительных мощностей), возможность использования альтернатив — это деньги.
Чаще всего для того, чтобы не убивать каналы, достаточно тегировать траффик, только литься будет дольше. Всё равно есть часы наименьшей нагрузки. А вот когда надо именно относительно быстро перелить данные (а такое иногда бывает) — то тут уже надо что-то придумывать. И у перевозки на грузовиках есть куча минусов, типа неизбежных потерь дисков при погрузке-разгрузке, перевозке и т.д., требуется какая-никакая логистика, да и банально полки с дисками тяжёлые, инженеры ДЦ могут и не согласится забесплатно их тягать целый день. Но зато очень быстро.
Забавно, но: https://aws.amazon.com/ru/snowball/
Таки это заработало
https://aws.amazon.com/ru/blogs/aws/aws-snowmobile-move-exabytes-of-data-to-the-cloud-in-weeks/
Таки это заработало
https://aws.amazon.com/ru/blogs/aws/aws-snowmobile-move-exabytes-of-data-to-the-cloud-in-weeks/
Когда же мы говорим о больших передачах данных, например, между дата центрами, этот вариант не пройдет :)
Но, тем не менее, это не мешает использовать данный метод и крупным компаниями для передачи данных между датацентрами :)
К сожалению, я вынужден остаться голословным, так как этот удивительный для меня факт я узнал из личной беседы с европейскими коллегами о смысле жизни в системах передачи данных.
Хорошо что такие статьи появляются.
Только вот проблему cycle slip нормально так и не решили… Дополните?
1T уже вышел из лаборатории в январе сего года.
www.nec.com/en/press/201301/global_20130117_02.html
Только вот проблему cycle slip нормально так и не решили… Дополните?
1T уже вышел из лаборатории в январе сего года.
www.nec.com/en/press/201301/global_20130117_02.html
Вообще они и ранее интересные данные выкладывали: www.oiforum.com/public/documents/Neda_AO-OFDM_WS08_Presentation_final.pdf но информации очень мало.
Пока это все тесты. Но в данном случае используется не просто увеличение сложности модуляции но и применения фильтров найквиста для формирования суперченела, фактически это агрегат из 100G каналов с минимальными межканальными интервалами, работающее как единое целое. И каждый subcarier это отдельный передатчик. И это отдельная тема для отдельной статьи. К сожалению пока данных очень мало по этой теме.
Касательно Slip, для 100G де факто проблема не имеет значения. Реальное проявление стоит ожидать в >400G системах, но они еще в стадии разработки.
Пока это все тесты. Но в данном случае используется не просто увеличение сложности модуляции но и применения фильтров найквиста для формирования суперченела, фактически это агрегат из 100G каналов с минимальными межканальными интервалами, работающее как единое целое. И каждый subcarier это отдельный передатчик. И это отдельная тема для отдельной статьи. К сожалению пока данных очень мало по этой теме.
Касательно Slip, для 100G де факто проблема не имеет значения. Реальное проявление стоит ожидать в >400G системах, но они еще в стадии разработки.
Да понятно что это суперканал )
Данных достаточно, в частности в библиотеке IEEE, но все статью по $10 за штуку…
Но узкие специалисты мне подсказывают что на 100G на магистралях slip имеет место, и является ощутимой проблемой.
Данных достаточно, в частности в библиотеке IEEE, но все статью по $10 за штуку…
Но узкие специалисты мне подсказывают что на 100G на магистралях slip имеет место, и является ощутимой проблемой.
Спасибо за статью, очень познавательно!
Для сравнения ещё стоит отметить, что существующие сейчас порты 100GbE и 40GbE, например, коммутаторов Cisco, Juniper или Extreme на физическом уровне устроены как несколько (4 или 10) интерфейсов со скоростью 10 или 25 Гбит/с.
Поэтому, как правило, когерентные DWDM-транспондеры для интерфейсов 100G работают как мультиплексоры для нескольких низкоскоростных потоков.
Для сравнения ещё стоит отметить, что существующие сейчас порты 100GbE и 40GbE, например, коммутаторов Cisco, Juniper или Extreme на физическом уровне устроены как несколько (4 или 10) интерфейсов со скоростью 10 или 25 Гбит/с.
Поэтому, как правило, когерентные DWDM-транспондеры для интерфейсов 100G работают как мультиплексоры для нескольких низкоскоростных потоков.
Клиентские порты действительно работают так, но там используется простейшее волновое уплотнение, просто для передачи по одному волокну. В частности там используется уплотнение с сеткой CWDM.
Для DWDM сетей 100G возможна как передача «чистого» 100G так и агрегата 10*10G.
Для DWDM сетей 100G возможна как передача «чистого» 100G так и агрегата 10*10G.
В OTN сетях ODU4 тоже передаётся как агрегация 10x10? Или вы имеете в виду 10xODU2?
Нет, в OTN сетях OTU4 это стандартизированый контейнер верхнего порядка со скоростью порядка 112Гбит/c. Агрегат передается в этом контейнере посредством например 10*ODU2, 2*ODU3 и т.д. В принципе ничто вам не запрещает передавать 100*1Ge, но это не очень выгодно экономически.
Экономическая выгода зависит от клиентов, которые в этом контейнере передаются. Мы сейчас внутриобластные линки поднимаем на одну ступень (2x1->10, 10->40), при этом на данный момент десятки хватает, так что если найдутся желающие, то можно передавать ODU2+ODU2+8xODU1, почему бы и нет? Всё равно половина контейнера свободна будет ещё долго.
Да, с небольшим уточнением: я говорил об электрической части клиентских интерфейсов.
То есть независимо от вида оптического транспорта (есть даже варианты трансиверов с оптическим шлейфом, без всяких CWDM/DWDM) электрический интерфейс максимум 25Gbit/s.
То есть независимо от вида оптического транспорта (есть даже варианты трансиверов с оптическим шлейфом, без всяких CWDM/DWDM) электрический интерфейс максимум 25Gbit/s.
А расскажите каким образом там производится балансировка? По какому алгоритму трафик раскладывается по линкам?
К сожалению настолько глубоко я стандарт 802.3 не знаю, но его тех описание можно скачать тут standards.ieee.org/getieee802/download/802.3ba-2010.pdf и ознакомится. Кроме того я натыкался вот на эту статью, она достаточно интересна.
Посмотрю, спасибо.
Не за что. Кстати вспомнил еще был хороший пост тут: habrahabr.ru/post/102432/ как раз там немного рассказано про балансировку.
На пороге новые сложности, в данный момент идут активные исследования передач на скоростях 400Gbit и 1000Gbit (1Tbit) в секунду и думаю, что через пару лет и эти технологии шагнут из лабораторий в мир практического использования.
Позволю себе добавить, что 400G и 1T активно показывали год назад на MWC, несколько дней назад ALU похвасталась запуском 400G на сети Orange в комерческую эксплуатацию, а Huawei показал 2T (в вариантах 400ГГц на сравнительно короткие, и 600ГГц на длинные растояния)
Позволю себе добавить, что 400G и 1T активно показывали год назад на MWC, несколько дней назад ALU похвасталась запуском 400G на сети Orange в комерческую эксплуатацию, а Huawei показал 2T (в вариантах 400ГГц на сравнительно короткие, и 600ГГц на длинные растояния)
ну вот, весь мир пробует 100G скорости, а у нас в Норильском промышленном районе всё еще 1 Мб/с стоит 7 тыс.руб/мес. И то не понятно что там с заявленной скоростью. Когда же до нас цивилизация дойдет? =(
Sign up to leave a comment.
Что такое 100G?