Pull to refresh

Comments 16

У нас есть оптическое кольцо между нашими ЦОДами с выходом на MSK-IX для прямого выхода в «большой Интернет»

На RS MSK-IX сейчас около 18К префиксов, в «большом Интернете» порядка 400К.

Если метеорит попадет в «КРОК ЦОД», то как «Заказчик ЦОД» будет ходить в Интернет? К сожалению, не понял из текста, а на схеме там выхода в Интернет нет.
Уточните, пожалуйста, вопрос. Сеть ЦОД КРОК имеет выходы на М9 и М10 посредством 12 провайдеров связи. Причем разные провайдеры заведены в разные ЦОД. Если один ЦОД из цепочки выйдет из строя, то связность остальных с Интернет не будет нарушена.
На первой картинке «Заказчик ЦОД» не имеет выхода в Интернет. «Заказчик ЦОД» есть на второй картинке?
Если заказчик пользуется общими каналами связи КРОК, то его ЦОД связан с сетью ЦОД КРОК по сети Интернет. КРОК предоставляет связь со своим ЦОД через Интернет посредством двух каналов от независимых телеком-провайдеров. Эти каналы проложены по двум разным канализациям до ЦОД, в котором распложено облако. Если заказчик провел в ЦОД “свои” каналы связи (к примеру точка-точка), то он подключает свой ЦОД к ЦОДу КРОК посредством этих каналов.
Думаю, у заказчика такого уровня есть своя действующая инфраструктура, которая кроме всего прочего обеспечивает выход в интернет, помимо КРОКа…
что-то не врубаюсь, в чем тут ценная информация. Ну проект, ну два датацентра. Изюминка где?
мерси за минускарму, придется развернуть:

статья не сообщает ни о чем новом в техническом или бизнес-плане, это скорее executive report для внутреннего потребления, но мы же не stakeholders. Те, кто в теме, ничего нового не узнали, а те кто не в теме, вообще пролистнули.
UFO just landed and posted this here
Мой комментарий ниже был для Вас, но промахнулся.
Здесь особо и нечего обсуждать, просто хорошая реализация поставленной задачи.
UFO just landed and posted this here
Риски заказчика понятны. Сведены к минимуму. А риски интегратора? Какова по итогу оказалась рентабельность проекта, с учётом того, что под проект заказчика пришлось ставить дополнительное оборудование?
Львиная доля сервисов оказывается на базе высокостандартизированной облачной платформы, все операции по управлению которой производятся в self-service режиме. Это позволяет обеспечить высокую рентабельность проекта. А физическое оборудование в данном проекте скорее позволяет лишь выйти за рамки стандартных сервисов облачной платформы и удовлетворить нестандартные требования заказчика — роль оборудования вспомогательная, и оно не сильно влияет на рентабельность.
Зная цены на специфическое оборудование типа того же тяжёлого UNIX cервера БД, сильно сомневаюсь что рентабельность не страдает. Впрочем финансовая сторона неозвучена, поэтому какие-то выводы делать невозможно. Хотя во многом именно финансы оказывают существенное влияние на принятие большинства технических решений. И это на самом деле самое интересное. Потому как по настоящему оригинальные решения находятся именно в результате ограниченности бюджетов.
А как хеджируются риски связанные с приобретением дорогого кастомного железа, к примеру «тяжелых» серверов? КРОК покупает их в надежде на взлёт проекта и остаётся с неликвидным железом в случае провала стартапа? Или есть поставщики у которых это железо тоже арендуется?
Рискну полюбопытствовать — не имеет ли отношения этот «взлетевший» проект к одному амбициозному банку с богатой историей его основателя?
Sign up to leave a comment.