Pull to refresh
7
0
Венедикт Слюсарев @behek

Архитектор облачных решений

Send message

Ложка тоже хороша к обеду.

Карты без GPS многим тоже не помогают. А Колумб по компасу и часам плавал, не имея карты, туда и обратно.

Можно ещё глаза завязать.

А вообще "рабочая станция для разработки" чего и под чего? Программки под эту железку на этой железке? Как хобби, если у вас больше ничего нет, круто.

Наверное будет актуально в постапокалиптическом мире, но точно не в современном.

прошло три года, из них полтора активной эксплуатации
они живы, но потрёпаны
Если у вас ВМ свопится, то это плохой провайдер. Тут лучше что-то другое придумать. Но если свопится, то быстро.
Мы не говорим про конкретного облачного провайдера, в каких-то случаях резервирование память на 100% оправдано и своп не создаётся. Но часто операторы пытаются экономить, но это не значит, что ВМ будет свопится туда. Просто не все клиенты оптимально используют память, и очень много выделено для Вм, но фактически не используется никогда.

Также речь не только про своп, а и про дамп памяти ВМ, при её приостановке, например.
Диски могут быть тонкими и дедуплицироваться, ядра можно делить между несколькими ВМ, а память если используется, то практически монопольно
Не согласен, от проблем с СХД и отказа вычислительного кластера защищают оба решения.
И выбирать из них стоит отталкиваясь от стоимости вашего RTO\RPO.
Репликация срабатывает по расписанию раз в несколько минут, и каждая дельта занимает место на СХД и является снепшотом на резервной машине. Хранить бесконечное количество реплик не получится.
Момент атаки можно легко пропустить и установить время её начала не всегда быстро и легко.
Так что, от крипторов только резервное копирование на удалённую площадку.
Говоря про DR-план, я не имею ввиду общий план для всего ЦОДа, а только про рассматриваемый продукт. И сокращение DR употребляю — как короткое название продукта, о котором пишу. Видимо небольшой путаницы не удалось избежать.

Моя коллега готовила статью как раз на эту тему, Вот тут можно прочитать подробнее
Вы можете арендовать каналы связи между разными облаками и своими офисами, это не отличается от аренды каналов в ЦОДах. Например, некоторые клиенты объединяют свои ресурсы в нашем облаке с облаком Амазона. С российскими операторами ещё проще и дешевле. Я писал об этом в своей статье, это реально работает и не стоит космических денег.
Построить свой ЦОД очень дорого. Далеко не каждая крупная компания себе может это позволить.
Облака бывают разные, в том числе и закрытые, с различными уровнями защищённости и аттестованные для размещения государственных информационных систем, информационных систем обработки персональных данных и для работы с платёжными системами. У нас есть и такие. Вот тут можно детали посмотреть ts-cloud.ru/service/virtualnyi-data-centr-VDC, а еще вот пост моего коллеги про мифы при переезде habr.com/company/technoserv/blog/348982.
А зачем это маленькому инстансу, он же умрет просто на обработке сети.
Что будет, если туда подселить 10 подобных инстансов (по остальным ресурсам они, допустим, поместятся)?
Это же явный оверкоммит, еще и в таких объемах.

Трафик больше 1 Гбит/с уже хочет интерфейс 10Гбит/с
Попасть на соседа, который кушает почти весь канал своей небольшой машинкой — так себе удовольствие.

Это забота облачного оператора, чтоб клиенты не почувствовали.
Да и я что-то не нашел у вас на сайте про это. Есть «частное облако», которое выглядит как блейд с райзером, но стоимость у него ухх. Да и там тоже что-то ничего про 10 Гбит наружу нет, там в целом то всего 2х10 Гбит, как я вижу в конфигурации.

Мы используем порты 10 и 25 Гбит/с на наших серверах.

А с чем вы согласны то? Я же сказал ровно обратное — гигабайты сканов в S3, которые часто надо печатать на локальном принтере — не самый лучше выбор, если только S3 бэкап и не более (как и любое другое облачное хранилище).


Согласен я с вашем мнением, по поводу сетевого взаимодействия с принтером. И с тем, что предпочтительней не гонять тяжёлый трафик через внешний канал.
Коллега onlinehead меня опередил.
Добавлю про обучение.
а что в облаке этот пункт чудесным образом исчезает? Или вы хотите сказать, что с тем же aws разберется любой сисадмин?

Речь шла о железе. А с интерфейсом облака придётся дружить, я об этом писал, здесь я согласен.
Это, мягко говоря, не совсем правда. Зависит от того, что за облако и что за тип инстанса. Далеко не всегда нужен m5.12xlarge (с которого начинается 10 Гбит/с) с ценой в районе $2.304 в час без прекоммита (итого ~ 1700 долларов в месяц только за вычислительную мощность).

В нашем облаке это правда. Даже самый маленький инстанс может иметь интерфейс в 10Гбит/с без ограничения трафика внутри сети и дополнительных плат.
К тому же, никто не отменял требования к обратному каналу с терминального сервера до принтера в офисе, там тоже магии не происходит и на принтер приедет вероятно больше 1 ГБ данных при респечатке 1 Гб сканов, т.к. принтер все таки другими протоколами пользуется.
В таких случая разумно оставлять файлопомойку в офисе и делать к ней синхронизацию во облачный сторадж (S3 + Glacier, допустим), чтобы обеспечить сохранность.

Полностью согласен. Большой объём сканов действительно удобно хранить в S3. И с S3 приятней работать чем с кучей каталогов.

В первую очередь нужно понять, как бегает ваш трафик до файловой помойки. Если из офиса со стационарных рабочих мест, то видимо не стоит переносить. А если в офисе тонкие клиенты на рабочих местах и вы работаете через терминальный сервер, который тоже в облаке, то как раз стоит. И почту тоже. В облаке стандартный интерфейс у виртуальной машины 10Гбит/с. Плюсы, которые дает работа через терминальный сервер, я расписывать не буду.

Как нам не хватало такого железа 10 лет назад. Будущее приходит.
Наг хот и медленно, но реализует в своих железка хотелки операторов.
1

Information

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