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

Зачем нужно использовать два роутера

Не секрет, что Интернет в наше время становится доступен на все более космических скоростях. Старенький роутер на подобие моего Dir-300 уже не смог тянуть канал с новым 60 Мбитным тарифом, и встал вопрос покупки нового девайса, роль которого пришлась по плечу новенькому WNDR4000. Не буду утомлять дальнейшими подробностями и перейду сразу к самому интересному… Нет, не к тестам, которых уже и так немало, а к такому интересному вопросу, как настройка Wake on Lan на домашнем компьютерном парке.

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

А как же альтернативные прошивки, спросите вы? Да, тот же DD-WRT действительно решает проблему. Но в новых мощных роутерах альтернативная прошивка приводит к прямо-таки катострофическому падению производительности. Стоит ли ради возможности WOL терять преимущества хорошего, специально приобретенного роутера — вопрос грустный. Но как оказалось есть интересное решение.

Вступление, отступление или просто жалоба на судьбу злодейку и провайдера

Пишу этот хабрапост в надежде сделать жизнь московским абонентам Акадо, сидящим через роутеры на дорогих тарифах, чуточку понятнее и, может быть, легче…
(Сразу оговорюсь — я пока что эникейщик или продвинутый пользователь, так что пост не претендует на профессионализм, зато может оказаться доступным, понятым и по делу)
Приблизительная хронология событий такова:
Весна 2012 — покупка роутера MikroTik RB751G-2HnD с целью получить полную стабильную скорость интернета (50Mbit/s в обоих направлениях)
Лето — как-то работает, но вай-фай почему-то периодически выдаёт пинги 200мс до роутера, а нагрузка на ЦП при ообычном веб-сёрфинге ~40%
Начало ноября — ситуация обостряется, пропускная способность в вечернее время падает до 20мбит в лучшем случае (обычно не больше 5), замечаю что ночью проблема отпадает сама собой, возникают смутные подозрения…
Вторая половина ноября — вызов аварийщиков, звонки во все колокола и вселенский ахтунг.
28 ноября решение проблемы.

Splunk — это система хранения и анализа логов. В двух словах принцип работы можно описать так: есть сервер Splunk, который хранит, индексирует и позволяет анализировать логи, и есть рабочие машины (сервера), которые эти логи создают и передают на сервер Splunk. Сервер Splunk в свою очередь может быть кластером из нескольких физических машин, между которыми распределяется хранение информации, и которые используются для ее обработки по технологии MapReduce. Способов передавать логи с рабочих машин очень много: через специальную программу forwarder, которая умеет быстро и эффективно отсылать изменения логов на сервер, через технологии типа NFS/SMB, или SNMP, можно самостоятельно отсылать данные в Splunk по TCP/IP (например, вместо того, чтобы писать в файл). Под Windows Splunk умеет брать данные из Windows Events, Performance Counters или Реестра.

Введение

Любое действие занимает некоторое время. Одни действия требуют меньше времени, другие больше, одни повторяются часто, другие, напротив, очень редки. Любой наш день состоит из множества действий, и занимают они 24 часа нашего времени. А на что же мы тратим ежедневно эти 24 часа?

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

Кратко о технологии 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. После получения ответов мы опубликуем их отдельным постом в формате хабраинтервью.



Успехов!