Pull to refresh
43
0
Oleg Alekseenko @router

User

Send message

GreenBushDC прошел сертификацию независимого международного института
Uptime Institute по уровню отказоустойчивости — Facility Tier III

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

Мне тоже хотелось подешевле. Конечно нагуглился Ikea Bekant. Но быстро нагуглился и тест устойчивости, например, https://www.youtube.com/watch?v=n3sYS0xUq1E

Хорошее подстолье за 215$ (без доставки и таможни) было найдено на alibaba, но продавец сообщил, что отгрузка только от 3 штук, и посоветовал ресейлера в России - shapdesk

В итоге золотой серединой по цене вышел stolsmart. Место действия - default city.

Резерв организован посредством HSRP

Вы не только растянули L2 между площадками, вы еще используете протокол без свидетелей или каких-то защитных механизмов через резервирование сигнализации (например, BGP), который может легко привести к split brain. Программный или аппаратный сбой между «PE» приведет к появлению по 1 активному и независимому шлюзу на каждой площадке «катастрофоустойчивого» облака.

Проблемы со связностью и split brain маловероятны, так как каналы между площадками идут независимыми трассами, на территорию ЦОДа заведены через разные кабельные вводы и подключены к оборудованию в разных энергоцентрах

У вас ограниченный SPOF анализ для «катастрофоустойчивого» облака: рассмотрите выше каналов — сбои в аппаратной (например, ASIC) или программной частях (например, *IOS*), а так же подумайте про человеческую ошибку (например, конфигурацию оборудования). Для HSRP я привел его выше: как видите, энергоцентры и кабельные вводы не спасают, когда все сводится в 1 логическую точку резервирования шлюза.

L2 растянут между площадками, но это не означает единый домен отказа

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

Остальные клиенты при этом не пострадают, так как на уровне сетевого оборудования настроен storm-control.

У большинства производителей оборудования strom-control работает на портах стыков, но не на L2 домен индивидуально. У вас где-то trunk с набором VLAN нескольких клиентов. 1 из этих клиентов сделал плохое и в его VLAN шторм. Как storm-control вырежет шторм только для этого клиента? Если вы не можете ограничить шторм в 1 L2 сегменте, то storm-control без разбора подропает бродкасты всех L2 сегменты в trunk и L2 сломается у всех клиентов. Если в этом trunk еще идет и L2 для HSRP, то сломается и ваша сигнализация шлюза.
SAN, картинки про SAN, отказы по SAN…
Что с IP и Ethernet происходит, какие DR планы там?
Все клиентские сети заведены на обе площадки через общую сетевую фабрику. На каждой площадке работает Provider Edge (PE), на котором и терминируются сети клиента. PE объединены в общий кластер.

Что будет, если один из PE решит сбойнуть аппаратно или программно, как остальные PE изолированы от этого сбоя?
Как вы поступаете с префиксами global unicast для интернет, которые должны быть видны и катастрофоустойчивить с двух площадок? Что будет при проблемах со связностью между двумя площадками и внешними префиксами в момент split brain?
Как вы растянули L2 между площадками? Как известно, растянутый L2 делает из двух площадок один домен отказа и облако получается неустойчивым к катастрофам.
Мы не оператор связи

На вашем сайте указаны лицензии на ПД и ТМ, а так же в вашем дороговоре-оферте вы оказываете услуги связи от этих лицензий — вы оператор связи, на вас распростряняются требования по установке СОРМ-2/3 и «Яровая».
Большее число компаний не принадлежит Яндекс, это не означает, что Яндекс.Облако обречено на отсутствие клиентов. Яндекс в аплинк взяли, домены используют. Аж 25% владения, могли бы и Яндекс как ЦОД или облако рассмотреть. Или в СберКлауд встать тогда уж. В этом и был вопрос: почему своя инфстраструктура при наличии дружественных облаков и ЦОД у владельцев.
Яндекс.Деньги не рассматривали нахваливаемые Яндекс надежные ЦОД Яндекс? В них, например, даже Яндекс.Облако стоит, которое, якобы, внутри потребляют, как dog food.
Вы точно знаете разницу между TIER III и Tier 3? Проверьте пожалуйста вашу таблицу uptimeinstitute.com/uptime-institute-awards/list? Например, у Selectel не TIER III.

Только сегодня Яндекс рассказывал, когда не TIER III habr.com/ru/company/yamoney/blog/481340
Александр — mitradir, про какой из Яндекс речь в статье?

4 других Яндекс даже не подписали свои маршруты:


При этом у всех 5 Яндекс один и тот же mntner, что намекает на единое управление. Но контакты не всегда едины.

Сейчас мы включили проверку маршрутной информации на стыках с точками обмена трафика и приватными пирингами.

Яндекс принимает от Яндекс по приватному пирингу невалидный маршрут?
Как вы относитесь к такому подключению с сошедшей изоляцией

Является ли это нарушением регламентов/нормативов элекробезопасности или ЦОД?
(4е фото в вашем посте)
Интерфейс постоянно бросается в глаза кусками Redmine. Это вдохновление, или ядро его?
Вопрос был шире. Яндекс сообщает, что использует свое облако под собственные проекты: «питается своей собачьей едой». Не думаю, что каждому проекту в Яндекс разрешено тратить ресурсы на изобретение и поддержку своего способа шифрования каналов между ЦОД: это затраты не только на уровнях модели OSI. Это или является частью IaaS, или не является.
По-моему, если клиент не доверяет поставщику, то он не пользуется IaaS этого поставщика, т.к. он не доверяет не только каналам, но и ПО, firmware, «железу» и сотрудникам поставщика услуг. Не вижу ничего плохого, чтобы к красивым картинкам про много сотен гигабит между ЦОДами добавить слова про то, зашифрован трафик, или нет: это поможет заказчику построить свою модель рисков.
Уход же от темы ИБ на about:cloud, в статье и даже комментариях вызывает лишь большее недоверие.
Надеюсь, обещания и планы будут выполнены, маркетинг снимет с вопросов ИБ табу.
Мне только учтонить: в т.ч. ожидается развернутая статья про регулирование в области связи по российскому законодательству? Очень смущает продажа трафика и отсутствие лицензий в договоре-оферте на сайте.
Вопросы по информационной безопасности:
  1. Судя по вашему описанию, у вас на compute используется GNU/Linux, KVM, QEMU. Но ни в одной презентации не затронуты вопросы обновления этих популярных составлящющих частей, хотя бы от «уязвимостей с логотипами». Можете описать пожалуйста теущее состояние (в т.ч. про «уязвимости» в CPU) и подход к обновлениям?
  2. Вы сообщате, что на выбор пользователю доступно 3 ЦОДа и возможность IP связности между облаками в них. Шифруется ли трафик по сети Яндекс между ЦОДами, если да, то как? Во время шума о PRISM был разговор о том, что ЦОДы ИТ гигинтов США безопасные, но не транспорт между ними, где трафик и уходит на анализ.


Вопросы российской реальности:
  1. Является ли ООО «Яндекс.Облако», с которым заключается договор об оказании услуг и который продает, судя по тарифам, исходящий интернет-трафик, оператором связи и есть ли у него лицензии в области связи? Если нет, то на каком основании продается интернет-трафик?
SSH из интернета на продуктив технологически обязателен для работы S3, или это тестовый стенд (IP со схемы)?

% nmap -p 22 92.242.47.232/29
Nmap scan report for 92.242.47.233
Host is up (0.043s latency).

PORT STATE SERVICE
22/tcp closed ssh

Nmap scan report for 92.242.47.234
Host is up (0.041s latency).

PORT STATE SERVICE
22/tcp open ssh

Nmap scan report for 92.242.47.235
Host is up (0.042s latency).

PORT STATE SERVICE
22/tcp open ssh

Nmap scan report for 92.242.47.236
Host is up (0.050s latency).

PORT STATE SERVICE
22/tcp open ssh

Nmap scan report for 92.242.47.237
Host is up (0.051s latency).

PORT STATE SERVICE
22/tcp open ssh

Проходя мимо:

% host -t a ruvds.com
ruvds.com has address 193.124.0.4

% host 193.124.0.4
4.0.124.193.in-addr.arpa domain name pointer ptr.5x00.com.

% curl 5x00.com
<html><head><title>Object moved</title></head><body>
<h2>Object moved to <a href="https://ultravds.com/">here</a>.</h2>
</body></html>

ruvds и ultravds — одно и тоже?
Прошу извинить, если уже поднимался вопрос, но зачем при старте произходит попытка отрезолвить на вид рандомные DNS имена:
wireshark




ОС: GNU/Linux.
search lan в /etc/resolv.conf
Эта первая инсталляция такого решения в РФ.

Первая инсталляция по какому критерию
  1. кроссивровка на MTP
  2. у вашего поставщика СКС
  3. у вас

?

Если вы имели в виду пункт 1, то заранее огорчу: это не первая инсталляция в России.
Простите, RFC6296: IPv6-to-IPv6 Network Prefix Translation

RFC6296 — IPv6-to-IPv6 Network Prefix Translation or NPTv6 (http://www.ietf.org/rfc/rfc6296.txt) define a methodology to allow for the use of a Global Unicast Address (GUA) on the «outside» of an NPTv6 gateway and another GUA (http://www.ietf.org/rfc/rfc3587.txt) or Unique Local Address (ULA — www.ietf.org/rfc/rfc4193.txt) on the «inside» of the NPTv6 gateway.

via cisco.com

Information

Rating
Does not participate
Location
Москва и Московская обл., Россия
Registered
Activity