IT-инфраструктура *

Кратко о технологии FCoE
FCoE (Fibre Channel over Ethernet), представляет собой ключевой протокол для поддержки унифицированной матрицы коммутации ЦОД, позволяющий консолидировать инфраструктуру ЦОД, повышать эффективность управления, а также наращивать гибкость и производительность инфраструктуры. Следуя курсу на использование Ethernet для унификации подключений в ЦОД, компания Cisco поддерживает протокол FCoE в своих ключевых продуктах, в том числе в коммутаторе для сетей дата-центров Nexus 5000 и в новой системе унифицированных вычислений UCS (Unified Computing System), которая объединяет вычислительные и сетевые ресурсы для поддержки виртуализации. Применение одной и той же физической среды для соединения серверов и сетей хранения данных SAN (Storage Area Network) упрощает серверную и сетевую инфраструктуру, а также инфраструктуру хранения данных.

Технология Fibre Channel over Ethernet (FCoE) представляет собой очередной этап эволюции консолидированных сетей хранения данных. Спецификация стандарта была предложена комитету T11 Национального института стандартизации США ANSI (American National Standards Institute) сообществом ведущих ИТ-компаний, в числе которых IBM, Intel, Brocade, Cisco, EMC, Emulex, Nuova, QLogic, Sun Microsystems.

В статье описывается включение FCoE на коммутаторе Cisco Nexus 5000

С каждым годом скорость интернета — как последней мили, так и магистральных каналов становится все выше. Лишь одно неизменно — латентность уже уперлась в физические ограничения: скорость света в оптоволокне — около 200тыс километров в секунду, и соответственно, быстрее чем за ~150ms ответ от сервера через атлантический океан не получить в обозримой перспективе (хотя конечно есть изыски, вроде оптоволокна с воздушной сердцевиной или радиорелейной связи, но это для простых смертных едва-ли доступно).

Когда мы пытаемся например из России открыть web-сайт, расположенный в США (его NS сервера вероятно там же), и домен не нашелся в DNS-кэше вашего провайдера — то ждать придется долго даже на гигабитном интернете, возможно даже целую секунду: пока мы через океан получим имена NS серверов домена, пока разрезолвим их IP, пока отправим и получим собственно сам DNS запрос…

Пару лет назад Google завела свои публичные DNS сервера, а для агитации перехода на них — они разработали утилитку NameBench, которая прогоняет тесты DNS по вашей истории серфинга и показывает, насколько Google DNS быстрее DNS сервера вашего провайдера.

Но мне удалось сделать свой DNS сервер, который работает быстрее Google Public DNS, и в этой краткой заметке хочу поделится результатами.

Ким Дотком готовится к запуску нового проекта Me.ga, который состоится 19 января. Сайт Me.ga станет более мощной альтернативой Megaupload, с распределённым хостингом, шифрованием всех файлов на стороне клиента перед передачей на сервер, открытыми API для сторонних приложений и т.д. Заинтересованным хостерам предлагается заполнить заявку на сотрудничество.



Вчера Ким Дотком объявил об ещё одном мега-проекте: возрождении магистрали Pacific Fibre, которая должна соединить Новую Зеландию и США по дну Тихого океана. Проект стоимостью $400 млн предполагает удвоение пропускной способности бэкбона, строительство дата-центра, создание новых рабочих мест и — как дополнительный бонус — бесплатный интернет для всех жителей Новой Зеландии.

С теорией (1) (2) закончили — пора переходить к практике. В этой статье — о том, какие микроэлектронные заводы в России (и Белоруссии) существуют и что они могут делать, а также о самых крупных разработчиках собственно самих микросхем, и каких работающих результатов им удалось добиться.

Под катом — драматическая история о пластиковой электронике, российской «гуманитарной помощи» знакомой многим компании AMD и билетах Метро.

Ну и в дополнение — график показывающий как изменялось состояние российской микроэлектроники последние 22 года по сравнению с США и Китаем.

Возможное, многие из вас думали после ситуации с Фобос-Грунтом — что такого особенного в микросхемах для космоса и почему они столько стоят? Почему нельзя поставить защиту от космического излучения? Что там за история с арестом людей, которые микросхемы экспортировали из США в Россию? Где все полимеры?

На эти вопросы я и попробую ответить в этой статье.

Disclaimer: Сведения получены из открытых источников и могут быть не вполне точными. Я лично с военной электроникой не работаю, а кто работает — те статьи писать не могут. Буду рад дополнить и исправить статью.

Я хочу описать сложности, с которыми администратор может столкнуться при настройке Exchange для нескольких доменов. Я не буду вдаваться в подробности решения данных проблем, однако опишу в общих словах как их следует решать и предоставлю ссылки на ресурсы (Microsoft или блоги специалистов по Exchange) где описано подробно решение тех или иных сложностей.
Я стараюсь обхватить как можно больше «тонкостей», однако что-то мог и забыть :)

Кому интересно – под кат. Внимание: очень много букв!

Многие наверняка не раз задавались вопросом, почему процессоры, видеокарты и материнские платы которые мы покупаем в магазинах — разработаны и сделаны где угодно, только не в России? Почему так получается, неужели мы только нефть качать можем?

Сколько стоит запуск производства микросхемы, и почему при наличии 22нм фабрик, бОльшая часть микросхем по всему миру до сих пор делается на «устаревшем» 180нм-500нм оборудовании?

Ответы на эти и многие другие вопросы под катом.

Совместимость

Не секрет, что далеко не всё всегда 100% совместимо, хотя казалось бы все протоколы, разъёмы, API приложений стандартизированы, что ещё нужно для нормальной работы инфраструктуры ЦОД? Даже если иметь два компонента взаимодействующих друг с другом, произведённых одним производителем само по себе работать оно не обязано, если туда не залить точно проверенные именно для вашего случая прошивки и конфигурации. Все производители имеют матрицу совместимости, где собрано множество оттестированных комбинаций оборудования, их прошивок, подключений и приложений. Настройка ЦОД'ов далеко не тривиальный процесс и для его упрощения рекомендуется во-первых следовать лучшим практикам, во-вторых пользоваться матрицей совместимости, которые уменьшают количество потенциально проблемных мест. Так использование проверенных и оттестированых конфигураций упрощает и ускоряет процесс запуска и эксплуатации ЦОД, уменьшает фактор человеческой ошибки. Широко применяйте этот подход в вашей практике для уменьшения потенциальных проблем в инфрастурктуре ЦОД.

Современные системы мониторинга “из коробки” позволяют отслеживать практически все показатели отдельного узла системы, но обладают рядом существенных недостатков

• зная все об одном узле, о работе системы в целом они не имеют никакого представления — попробуйте из коробки выдать руководству “в данный момент у нас 1200RPS на фронте, 90% страниц отдается за 300мс, 95% за 650мc, системных ошибок и таймаутов происходит меньше 10 в секунду” (см картинку под катом)
• выход за рамки одного из системных показателей одного из узлов системы еще не значит, что стоит бить тревогу — возможно узел попал под повышенную нагрузку, или разработчики сменили алгоритм
• в рамках мониторинга отдельных узлов практически невозможно уследить постепенную деградацию сервиса — как правило он срабатывает только когда уже “ничего не работает”
• деградация производительности внешних сервисов не отслеживается в принципе (вас никогда не банил CDN?)

На исходной у нашей площадки более 1.000.000 уников, ~100.000.000 http запросов на фронтенд в сутки и развесистый, в плане сопровождения, зоопарк проектов. Набор ключевых слов — nginx, apache, php (двух вариаций), oracle. С заядлой периодичностью возникают ситуации “у нас все работает” по отдельно взятым зонам ответственности либо, что тоже не редкость, “у вас ничего не работает”. На границах ответственности идет сплошная передача тикетов.
Мы не стали изобретать велосипед и решили сделать мониторинг по времени и корректности отклика пользователю с отслеживанием отклика бекендов, а также какие из них были задействованы при обработке конкретного запроса. Ну и плюс наши объемы — не сильно большие, но несколько граблей по ходу изложения можно продемонстрировать.

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

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

.

Мы участвовали в тендере по разработке Private Cloud сервиса для одной крупной европейской организации. Цель данного тендера — предложить инфраструктуру, предоставляющую клиенту сервисы IaaS и PaaS. Ниже приведу ключевые моменты тех. задания:

• основными операционными системами являются Windows и Linux на платформе x86
• «стандартный» список ПО для PaaS сервисов (web, database, application server, etc.), включая базы данных Oracle
• желательно так же предложить Solaris x86
• инфраструктура должна располагаться в двух датацентрах (расстояние < 50 км)
• 6 типов виртуальных машин (от 1 vcpu до 10 vcpu)
• 4 сервиса (SLA): от бронзы (best effort) до платины (RPO: realtime, RTO: 2h)
• твердый заказ на 1000 виртуальных машин, с возможным ростом до нескольких тысяч

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

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

Доброго времени суток. Решил поделиться с вами своим пониманием этого вопроса, и механизма его решения, используемого в устройствах WAN оптимизации Silver Peak.

Итак, практическое большинство современных сетей, использует в своей основе пакетную передачу и протокол IP. Информация передается через сеть кусочками информации, и обычно размер этих кусочков варьируется от 1 байта до 1500 байт (Я имею ввиду полезную нагрузку). По пути через WAN сеть, такие пакеты могут пройти через великое множество маршрутизаторов и шлюзов. Некоторые из этих перевалочных пунктов вы можете увидеть при помощи утилиты Traceroute. Но это далеко не все реальные транзитные узлы, например вы не увидите здесь те узлы, через которые трафик прошел туннелированным (MPLS VPN, GRE и т.д.). При этом, с ненулевой долей вероятности, какой-нибудь из транзитных узлов будет в данный момент сильно загружен, и уничтожит ваш пакет, чтобы не допускать перегрузки сети. И чем больше таких транзитных узлов, тем больше вероятность потери пакета в сети.

С нами связалась пресс-служба министерства связи и массовых коммуникаций Российской Федерации и выразила желание завершить историю с вопросами бывшему министру Щёголеву, который, к нашему сожалению, более чем за год так и не нашел времени “чиркануть пару строк” пользователям сайта.

В связи с этим предлагаем следующий план действий:

1. В комментариях вы задаёте свой вопрос — строго в рамках профессиональной деятельности министерства и тематики ресурса. Коротко и ясно, без сарказма и троллинга, указав в начале одну из тематик вопроса: мобильная связь, интернет, почта, службы, законодательство, разное.
Флейм в комментариях не устрайвайте — за «интересные» вопросы просто голосуйте.
2. Мы агрегируем все вопросы, рассортировываем по полочкам и отправляем Н. А. Никифорову.
3. После получения ответов мы опубликуем их отдельным постом в формате хабраинтервью.



Успехов!

Увы, протест Википедии, ВКонтакте, Яндекса, БашИма, ЖЖ и многих других ни к чему не привёл. Как сообщает в твиттере и на сайте Лента.ру со ссылкой на ТАСС, проект был принят большинством голосов Единой России. Во втором чтении принят 441 голосом, в третьем — 434 голосами (по данным твиттера КПРФ). Хотя и в него и были введены некоторые поправки.

ВАЖНО! Совет при Президенте не одобрял принятие закона, см. UPD13 под катом. А как же тогда он прошёл так легко?
Так же стало известно, что список будет публичным. См. UPD14.

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

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

Сегодня на всех страницах ЖЖ была замечена ссылка на позицию журнала по поводу Законопроекта №89417-6

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

В борьбу включается всё больше крупных ресурсов, что не может не радовать.

Опубликована обновлённая схема подводных интернет-кабелей за 2012 год.

Украинскому правительству, видимо, понравился опыт проведения выборов в России, поскольку вчера, за четыре месяца до парламентских выборов в стране, премьер-министр Николай Азаров заявил, что на всех 34 тысячах избирательных участках Украины будут установлены веб-камеры для мониторинга хода голосования. По словам премьера, за парламентскими выборами в Украине можно будет наблюдать через веб-портал с любой точки мира.

По оценке сайта Watcher, набор из компьютера, веб-камеры, модема, систем крепления для каждого учатка обойдется в 600—700 долларов при самых оптимистичных раскладах. В целом, приобретение техники потянет на 20—25 млн долларов.

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

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