GreenBushDC прошел сертификацию независимого международного института Uptime Institute по уровню отказоустойчивости — Facility Tier III
Но ЦОД не прошел сертификацию, прошли только документы дизайна в 2015 году. Если за 7 лет ничего в инженерных системах ЦОД не менялось, то скорее всего он просто устарел. Если же менялось, то он не соответствует сертификации. Так?
Мне тоже хотелось подешевле. Конечно нагуглился Ikea Bekant. Но быстро нагуглился и тест устойчивости, например, https://www.youtube.com/watch?v=n3sYS0xUq1E
Хорошее подстолье за 215$ (без доставки и таможни) было найдено на alibaba, но продавец сообщил, что отгрузка только от 3 штук, и посоветовал ресейлера в России - shapdesk
В итоге золотой серединой по цене вышел stolsmart. Место действия - default city.
Вы не только растянули 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.
Как вы относитесь к такому подключению с сошедшей изоляцией
Является ли это нарушением регламентов/нормативов элекробезопасности или ЦОД?
(4е фото в вашем посте)
Вопрос был шире. Яндекс сообщает, что использует свое облако под собственные проекты: «питается своей собачьей едой». Не думаю, что каждому проекту в Яндекс разрешено тратить ресурсы на изобретение и поддержку своего способа шифрования каналов между ЦОД: это затраты не только на уровнях модели OSI. Это или является частью IaaS, или не является.
По-моему, если клиент не доверяет поставщику, то он не пользуется IaaS этого поставщика, т.к. он не доверяет не только каналам, но и ПО, firmware, «железу» и сотрудникам поставщика услуг. Не вижу ничего плохого, чтобы к красивым картинкам про много сотен гигабит между ЦОДами добавить слова про то, зашифрован трафик, или нет: это поможет заказчику построить свою модель рисков.
Уход же от темы ИБ на about:cloud, в статье и даже комментариях вызывает лишь большее недоверие.
Надеюсь, обещания и планы будут выполнены, маркетинг снимет с вопросов ИБ табу.
Мне только учтонить: в т.ч. ожидается развернутая статья про регулирование в области связи по российскому законодательству? Очень смущает продажа трафика и отсутствие лицензий в договоре-оферте на сайте.
Судя по вашему описанию, у вас на compute используется GNU/Linux, KVM, QEMU. Но ни в одной презентации не затронуты вопросы обновления этих популярных составлящющих частей, хотя бы от «уязвимостей с логотипами». Можете описать пожалуйста теущее состояние (в т.ч. про «уязвимости» в CPU) и подход к обновлениям?
Вы сообщате, что на выбор пользователю доступно 3 ЦОДа и возможность IP связности между облаками в них. Шифруется ли трафик по сети Яндекс между ЦОДами, если да, то как? Во время шума о PRISM был разговор о том, что ЦОДы ИТ гигинтов США безопасные, но не транспорт между ними, где трафик и уходит на анализ.
Вопросы российской реальности:
Является ли ООО «Яндекс.Облако», с которым заключается договор об оказании услуг и который продает, судя по тарифам, исходящий интернет-трафик, оператором связи и есть ли у него лицензии в области связи? Если нет, то на каком основании продается интернет-трафик?
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.
Но ЦОД не прошел сертификацию, прошли только документы дизайна в 2015 году. Если за 7 лет ничего в инженерных системах ЦОД не менялось, то скорее всего он просто устарел. Если же менялось, то он не соответствует сертификации. Так?
Мне тоже хотелось подешевле. Конечно нагуглился Ikea Bekant. Но быстро нагуглился и тест устойчивости, например, https://www.youtube.com/watch?v=n3sYS0xUq1E
Хорошее подстолье за 215$ (без доставки и таможни) было найдено на alibaba, но продавец сообщил, что отгрузка только от 3 штук, и посоветовал ресейлера в России - shapdesk
В итоге золотой серединой по цене вышел stolsmart. Место действия - default city.
Вы не только растянули L2 между площадками, вы еще используете протокол без свидетелей или каких-то защитных механизмов через резервирование сигнализации (например, BGP), который может легко привести к split brain. Программный или аппаратный сбой между «PE» приведет к появлению по 1 активному и независимому шлюзу на каждой площадке «катастрофоустойчивого» облака.
У вас ограниченный SPOF анализ для «катастрофоустойчивого» облака: рассмотрите выше каналов — сбои в аппаратной (например, ASIC) или программной частях (например, *IOS*), а так же подумайте про человеческую ошибку (например, конфигурацию оборудования). Для HSRP я привел его выше: как видите, энергоцентры и кабельные вводы не спасают, когда все сводится в 1 логическую точку резервирования шлюза.
У вас HSRP в едином домене отказа живет, от сбоя в нем пострадает большинство клиентов. Домен отказа характеризуется не только штормами, но и консистентостью сигнализации, чего L2 гарантировать не может.
У большинства производителей оборудования strom-control работает на портах стыков, но не на L2 домен индивидуально. У вас где-то trunk с набором VLAN нескольких клиентов. 1 из этих клиентов сделал плохое и в его VLAN шторм. Как storm-control вырежет шторм только для этого клиента? Если вы не можете ограничить шторм в 1 L2 сегменте, то storm-control без разбора подропает бродкасты всех L2 сегменты в trunk и L2 сломается у всех клиентов. Если в этом trunk еще идет и L2 для HSRP, то сломается и ваша сигнализация шлюза.
Что с IP и Ethernet происходит, какие DR планы там?
Что будет, если один из PE решит сбойнуть аппаратно или программно, как остальные PE изолированы от этого сбоя?
Как вы поступаете с префиксами global unicast для интернет, которые должны быть видны и катастрофоустойчивить с двух площадок? Что будет при проблемах со связностью между двумя площадками и внешними префиксами в момент split brain?
Как вы растянули L2 между площадками? Как известно, растянутый L2 делает из двух площадок один домен отказа и облако получается неустойчивым к катастрофам.
На вашем сайте указаны лицензии на ПД и ТМ, а так же в вашем дороговоре-оферте вы оказываете услуги связи от этих лицензий — вы оператор связи, на вас распростряняются требования по установке СОРМ-2/3 и «Яровая».
Только сегодня Яндекс рассказывал, когда не TIER III habr.com/ru/company/yamoney/blog/481340
4 других Яндекс даже не подписали свои маршруты:
При этом у всех 5 Яндекс один и тот же mntner, что намекает на единое управление. Но контакты не всегда едины.
Яндекс принимает от Яндекс по приватному пирингу невалидный маршрут?
Является ли это нарушением регламентов/нормативов элекробезопасности или ЦОД?
(4е фото в вашем посте)
По-моему, если клиент не доверяет поставщику, то он не пользуется IaaS этого поставщика, т.к. он не доверяет не только каналам, но и ПО, firmware, «железу» и сотрудникам поставщика услуг. Не вижу ничего плохого, чтобы к красивым картинкам про много сотен гигабит между ЦОДами добавить слова про то, зашифрован трафик, или нет: это поможет заказчику построить свою модель рисков.
Уход же от темы ИБ на about:cloud, в статье и даже комментариях вызывает лишь большее недоверие.
Надеюсь, обещания и планы будут выполнены, маркетинг снимет с вопросов ИБ табу.
Вопросы российской реальности:
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
ruvds и ultravds — одно и тоже?
ОС: GNU/Linux.
search lan в /etc/resolv.conf
Первая инсталляция по какому критерию
?
Если вы имели в виду пункт 1, то заранее огорчу: это не первая инсталляция в России.
via cisco.com