Привет. Мы полностью переписали мобильную версию Хабра. Теперь все работает быстрее и выглядит современнее.

Всё точно и хорошо написано. Но вы не учли ещё момент — мнение об облаке складывается не только из опыта отношений с провайдером, но и из опыта работы с приложениями. И, например, если очередной облачный новодел CRM или НьюДокс экономит на хостинге или говорит клиенту «ваша база не бекапилась, потому что вы не платили за бекап, а хранится у нас она 2 недели и чтобы её забрать и смигрировать на другое решение, вам нужно заплатить столько-то тысяч рублей», понимаешь, что ну его, облако. Во всяком случае, нетехнические ребята думают именно так. И, увы, за такое поведение третьих разрабочиков своей репутацией расплачиваются дата-центры — кто будет там разбираться, чья вина…

Неплохая статья, но я как Попка-Дурак повторяю одно и тоже уже много лет: заказщик рискует бизнесом, вы рискуете контрактом. Это очень большой дизбаланс, особенно, если сумма этого контракта небольшая относительного всего вашего пула.
Да и с изъятием вы лукавите. В органах не идиоты работают — они не прийдут в машзал, они прийдут к вам, с постанавлением, и попросят доступ, который, на самом деле у вас есть всегда, чтобы вы не говорили клиентам.

Единственный способ, который против наших органов работает — это сервера в другой юрисдикции. Что собственно все и делают.

Нет, не все и не всегда — ПД никто не отменял.
При этом ПД могут быть и в другой юрисдикции, если их копия есть в российской. Это не запрещено.
ПД это персональные данные? Расписку с юзера берете что все ПД его не считается ПД на предприятии.
Мы рискуем бизнесом в неменьшей степени. Для любого провайдера репутация — ключевой вопрос. Любая проблема с облаком, если она сколько-нибудь серьёзна, становится публичной. Конечно, такая проблема вредит репутации и даже один инцидент может похоронить провайдера.  
Итого для нас проблема одного клиента может означать потерю многих или бизнеса с целом.  
Особенно это важно для нас, работающих со средними и крупными клиентами, где репутация вообще является главным аргументом для заказчика. 
Конечно, нам выгоднее сто раз перезаложиться и обеспечить максимальное резервирование. Что до изъятия, то скажу прямо: мы заинтересованы максимально отстаивать интересы клиента. В некоторых продуктах существует возможность включить шифрование, которое целиком лишит нас возможности даже теоретического доступа к данным. В остальных случаях мы подключаем нашу юридическую службу для оценки правомерности запроса. Как и в случае с отказоустойчивостью, это вопрос репутации.
какое такое шифрование, лишит вас теоретической возможности доступа к данным если у вас физически в распоряжении сервера?
Если не разбираетесь почитайте хотя бы habrahabr.ru/post/207306
Вариантов на самом деле много.
Если органам не предоставить ключи к расшифровке, то это отдельная статья УК, с перспективами в #. В данном случае шифрование имеет смысл только от третьих глаз (например, ИТ сервис провайдера)
Вы сами статью читали? там про хранение, ХРАНЕНИЕ, без использования файлов. Как только вы начинаете их использовать, значит ключи для расшифровки есть на машине. Да и к примеру лежит БД на шифрованном носителе, что дальше? при запуске бд, данные с этого носителя требуется расшифровать, не говоря уже о том, что можно просто подключится к бд и снять дамп.
во всем железе уже давно есть TPM, но не уверен в его секьюрности. реализации с использованием tpm и windows server вроде как ломали, но могу ошибаться.
Есть шифрование и на уровне контроллеров (например у Adaptec), но возможность расшифровки в этом случае всегда есть у владельца железа.
и у производителя :) (и у товарища офицера службы безопасности)
Насчет производителя не уверен, там физический ключ втыкается в контроллер.

Ключ шифрования можно не хранить на диске, вводить его при монтировании. Это усложнит задачу.

да можно, усложнит, кто спорит то? Вопрос в том, что полностью защитить данные просто невозможно, а тут говорят зашифруй и все будет
Данные полностью защищать и не надо. Достаточно усложнить процесс взлома настолько чтобы на это не хватило ума у сотрудника из отдела К. Этого достаточно чтобы он, почесав в затылке, оставил попытки взлома и побежал в магазин за паяльником начал искать другие методы.
вы наивный, им даже разбираться не надо будет, хостер сам все сделает, под угрозой отключения ВСЕХ стоек до конца следствия.
хостер сам все сделает
См. выше про Shielded VM
Или есть конкретные сведения про уязвимость технологии?

При монтировании вы введете мастер-ключ (или его часть, не суть), которым расшифруете собственно ключи шифрования данных, которые так и останутся в памяти.

Тогда облачному провайдеру достаточно сообщить вам о следственных действиях и выключить ваши виртуалки. Вроде бы это ничего не нарушает.
Это пример. При желании сами данные можно записывать и забирать в зашифрованном виде.
Свежий пример системы документооборота: документы шифруются на стороне клиента. Администратору сервера (хоть локального, хоть облачного) доступна база данных документов, но не тексты. Между лицами, имеющими права доступа к документу, ключ шифрования пересылается не через сервер.
НЛО прилетело и оставило эту надпись здесь.
зачем это хостеру? чтобы его обвинили в противодействии следствию?
НЛО прилетело и оставило эту надпись здесь.
у хостера просто вынесут все стойки с серверами «до окончания расследования» т.е. фактически у него выбор потерять бизнес или одного клиента. Что же выбрать? ума не приложу. Факты которые происходили, доказывают, что хостер выбирает сохранить бизнес.
НЛО прилетело и оставило эту надпись здесь.
Да, без проблем вынесут все 100 стоек. За пять минут. И загрузят. В багажник. Но если стоек немного больше, то… за десять минут.
А по поводу клиентов.
Так у провайдера то еще есть площадка, и не одна. И не только в России. И данные распределенные.
хоть один прецедент был, где хостер защищал клиента такой ценой?
даже админ кластера не знает, на каком сервере что находится

А потом клиент звонит в поддержку — "Ой, у нас сервер не отвечает". А поддержка пожимает плечами — хз где он.

НЛО прилетело и оставило эту надпись здесь.

Не надо путать "не знает" и "не может узнать". А вот должен ли он помогать "товарищам" под вопросом, хотя бы в виде сообщения данных своей учётки или создания для них учётки с нужными для "узнать" правами. Вот есть постановление "изъять сервера с данными такой-то компании", у админа спрашивают "где они?", он чистую правду отвечает "не знает", его спрашивают "а кто знает?", он чистую правду отвечает "никто", может даже с пояснением "у нас автоматическое распределение с постоянными миграциями, фиксируется в куче распределенных баз и конфигов, есть интерфейс, который это всё собирает", ему "ну так посмотри и скажи", а он "по должностной инструкции я эту информацию сообщаю только начальнику", начальник "по должностной инструкции я эту информацию запрашиваю только при наличии запроса от клиента или нашего юриста", юрист "в постановлении не указана наша обязанность извлекать информацию из наших систем, всё что мы знаем мы вам сказали, идите за другим".

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


А вы описываете схему прямого сопротивления расследованию. Вот это как раз и закончится тем, что "не хотите помогать — изымаем всё целиком".

И что? Далее делается заход на генерального «ай-яй-яй, должное взаимодействие вашими подчинёнными оказано не было (мол стерпим такое в последний раз), разберитесь кто у вас там чего должен или не должен и в указанные сроки предоставьте». На любого «дурачка» свой рычаг найдётся.
можно просто подключится к бд и снять дамп.
Не затрутнит алгоритм? Shielded VM, HotFixes установлены, LAN+WAN шифруем
( На случай снятия RAM планок «на ходу» с помещением в холодильник
— технология шифрование RAM от AMD )
хостер сам все сделает
Как? ( Именно хостер)
Мы говорим про облако те про ВМ, внедрить код в вм возможно, снять дамп оперативной памяти еще проще. О чем речь то? По технологии амд, не смотрел, думаю у очень малого числа вообще стоят райзен и еще у меньшего включена эта технология. И как я понял из маркетинга, она скорее нужна для не допуска доступа к оперативной памяти между разными ВМ, а не для не доступа хоста.
О чем речь то?

Об этом.


внедрить код в вм возможно, снять дамп оперативной памяти еще проще

Простым способом невозможно, и не проще. Да, обойти механизмы защиты можно (используя уязвимости оборудования, а не ОС, и вот тут разработчик ОС уже мало что может сделать), но для этого хостер должен целенаправленно готовить атаку, т.е. фактически проводить взлом собственной инфраструктуры, а не использовать штатные механизмы.

Мы говорим про облако те про ВМ, внедрить код в вм возможно, снять дамп оперативной памяти еще проще.
Простым способом невозможно, и не проще. Да, обойти механизмы защиты можно..., но для этого хостер должен целенаправленно готовить атаку

Для атаки, скорее, потребуется менять код прошивки UEFI + драйвера OS

На практике лучше и Shielded VMs, и огородить стойку сетчатым забором
И собственное видеонаблюдение

Эдакое частное облако на «удалённой площадке»

И слегка Ж-) дополню про механизмы защиты:
О чем речь то?
Об этом.
Shielded VMs in Windows Server 2016 ( by Kirill Kotlyarenko [MSFT] )

What Windows Server 2016 Shielded VMs include:
1.Shielded VM mode. In this mode, Secure Boot and vTPM are enforced, Saved State file and Live Migration traffic are encrypted. Also, some potentially unsecure VM extensions like Console access, keyboard and mouse drivers, COM/Serial ports and debugger are disabled.
2.BitLocker Virtual Disk encryption using vTPM. No need to provide an unlock code after reboot — use guest disk encryption everywhere without any administration overhead. Encryption keys are securely sealed inside virtual TPM device, that moves when the VM moves to another host.
3.Host Guardian Service (HGS). HGS is a Windows Server role that measures the health of Hyper-V hosts and releases keys to healthy Hyper-V hosts when powering-on or live migrating Shielded VMs. These two capabilities are fundamental to a Shielded VMs solution and are referred to as the Attestation service and Key Protection Service (KPS) respectively. HGS won't allow Shielded VMs to boot on any host that is not a part of pre-authorized guarded fabric (e.g. personal laptop of a rogue admin) or on a compromised host. It is expected that HGS service will be managed by different group of people inside service provider organization to keep the keys to the kingdom away from the kingdom.

Технология Shielded VM в Windows Server 2016
К аппаратной платформе VBS предъявляет следующие требования: наличие UEFI 2.3.1c для безопасной и контролируемой загрузки, TPM v2.0 для защиты ресурсов, расширения виртуализации (Intel VT-X, AMD-V), трансляция адресов (Intel EPT, AMD RVI), защита памяти гипервизором.

How Shielded VMs make Hyper-V Environment Secure
Benefits of shielded VMs
•A hardened VM worker process which helps in preventing tampering and inspection.
•Console access is blocked along with blocking Guest File Copy Integration Components, PowerShell Direct as well as other services providing potential paths with administrative rights to the VM from a user or process.
•Disks encrypted with BitLocker (keys protected by vTPM)
•Live migration traffic is automatically encrypted and providing encryption of saved state, checkpoints, runtime state file and even Hyper-V Replica documents.

Тут на самом деле еще вопрос в том, можно ли это вообще в российских реалиях законно реализовать (те же сервера с TPM 2.0 официальные поставщики простым смертным не продают, не знаю, как насчет крупных хостеров).

TPM 2.0... можно ли это вообще в российских реалиях
Есть с Shielded VMs и вариант «lite», для родной серверной. Там требования к оборудованию менее жесткие...
теоретической возможности доступа к данным если у вас физически в распоряжении сервера?
Теоретически никакое, т.к. данные в CPU в расшифрованном виде.
Есть предложение ограничится практической труднодоступностью со стороны хостера.
Мы можем содействовать заказчику в создании стокового шифрованного пула для хранения данных, ключами к которому будет обладать лишь заказчик такого пула.  Заказчик  берет  на себя риски потери ключей доступа к пулу и как следствие полной потери данных без возможности их восстановления.
Есть достаточно  много о средств шифрования, которые надежно защитят данные даже в случае физического доступа к серверам клиента. Если клиент  использует шифрование дисков (VeraCrypt ) или пулов в самой виртуальной машины, обладая эксклюзивным ключем, который остается у него всегда, то получить доступ туда мы не сможем при всем желании.
Шифрование лишает нас “простого” доступа к данным заказчика. При оценке допустимых мер по защите информации за основу всегда берется стоимость защищаемой информации. Любой алгоритм шифрования подвержен брутфорсу, для его выполнения нужны вычислительные мощности. А мы их используем для продажи нашим клиентам, а не с целью переборки ключей к данным заказчика.
Исходя из этого, репутационные потери для нас выше, чем одноразовая финансовая выгода от продажи информации клиента.
В некоторых продуктах существует возможность включить шифрование, которое целиком лишит нас возможности даже теоретического доступа к данным.

Т.е. когда придут из органов с решением о передаче доступа, а вы им ключи не выдадите?
И Техносерв будет идти под статью УК вместо клиента?
Слабо в это верится.
Я бы на месте юротдела техносерва тянул резину, дёргал клиента — WTF собственно, что у вас за тёрки с правоохранителями, разберитесь там, взрослые же люди?

А там или шах сдохнет, или ишак.
Я так понимаю будут обязаны «погасить/заснапшотить» машины клиента и выдать шифрованные образы. А дальше — ключ у клиента, с него и трясите.
Про ifolder не помните? Это не органы будут вас умолять показать конкретный сервер, это вы будете умолять органы изъять конкретный сервер вместо опечатывания всех ваших ДЦ.

Потому что у органов задача — пресечь распространение вредной информации. А что при этом страдают госзаказчики и критически важная инфраструктура — это не вина органов (с их точки зрения). Это якобы ваша вина — пустили себе порнографически политически ненадежных заказчиков — ни и получили приостановку бизнеса.

Так что в реальных историях (была ещё пара на Украине) — провайдеры бегают за органами и умоляют изъять только нужный сервер.
Именно так и делается — «вы сами выдадите нужную информацию или мы здесь всё отключим и будем долго разбираться, пока сами не найдём, а клиенты тем временем будут становиться всё довольнее?» — практически такими словами. Довелось как-то лицезреть (будучи немного в стороне, но информацию усвоил). И это только на одном даже не IT-предприятии, а если это хостинг — совсем интересно получается (там уже и клиенты клиентов страдают).
С дисбалансом согласен на все сто. Были коммерческие предложения о переходе на облако. Читали отделом со скепсисом, но руководитель приказал отработать. В итоге, по поводу гарантий хранения данных нам было заявлено, что все хранение и работа — ваш риск. Хотя в рекламе утверждалось обратное. В приватном разговоре сообщили, что помогло бы страхование, но увы, наши страховщики не могут такие вещи страховать, хотя на западе такое практикуется. Ну и не самое последнее — скорость работы с базами данных. Это сейчас в облаках ссд стоят, а раньше такое и не предлагали.
В органах не идиоты работают
.
Плюсов у поста конечно много. Но…
Знаете, по моему мнению к серверам, изъятым «на время расследования», в большинстве случаях до окончания расследования и не подходят. Ибо цель изъятия не получить данные, а парализовать работу бизнеса. И вот от таких случаев облако и защищает.
Если же цель именно получить данные, то возникает вопрос — работать на месте либо изымать данные. Если изымать, то необходимо озаботиться техническими и людскими средствами. Хостер конечно же не будет против выдачи ВМ, например в формате OVA. И размером так 100 терабайт. Ладно, не 100. Рассматриваем крохотную организацию с 10 Тб. Я конечно не знаю как там кухня у органов организована, но если сервера можно изъять «чтобы были более сговорчивыми» и сложить их на склад, то где разместить разместить данные с целью их анализа… А потом еще эти ВМ запустить, восстановить работу. Особенно если такая организация не одна. Одним словом сомнения меня берут, что с этим все так просто как с изъятием физических серверов.
Облако Битрикс24 — хороший пример, как можно обжечься, держа CRM и телефонию в одном месте. В прошлую пятницу их клиенты получили вынужденный выходной. И в понедельник ситуация повторилась, сократив рабочий день на несколько часов. При этом, техподдержка максимально дистанцировалась, сообщая, что им жаль и спрашивая, есть ли еще вопросы.
Судя по отзывам, многие задумались, стоит ли размещать ключевые сервисы в чужом облаке.
Да, по вашей ссылке наблюдается интересный психологический феномен, когда соболезнуют директору Битрикса, забывая, что в первую очередь пострадали его клиенты. Про компенсации, кстати, ни слова.
Ответ провайдера ещё смешнее.
Выводы: "… Обнаружена уязвимость. Расследование отдела К"
А кто ее устранять-то будет?
Как это ни странно, но в российских реалиях ведения конкурентного бизнеса такое как раз может быть.

Теория заговора mode ON.

CorpSoft это экс Cloud4Y. Экс — потому что у них, похоже, не очень заладилось с чистым IaaS и компания ушла в сегмент хостинга 1С, сменила торговую марку для нового бизнеса.

Падение 9 февраля, в пятницу.
Во вторник страна узнает, что Mail.ru и 1С теперь очень хорошие партнеры
www.cnews.ru/news/top/2018-02-13_mailru_nachnet_razdavat_gotovoe_rabochee_mesto

Mail.ru один из крупнейших клиентов (если не самый крупный) DataLine, в котором у CorpSoft наблюдались проблемы.
Mail.ru принадлежит USM Holding.
С последним было уже не мало интересных историй, связанных с ИКТ компаниями, самая громкая с ВКонтакте конечно.

Все это, конечно, чистое совпадение.

Потребовалось нам как-то замена жесткого диска, провайдер без промедления выполнил замену. Диск оказался не новый, не разбитый на разделы, но с файловой системой, но котором были чужие данные.
Диск оказался не новый, не разбитый на разделы, но с файловой системой, но котором были чужие данные.

ну так это проблемы клиента, при чем тут хостер/облако? Например тот же hetzner всегда предупреждает.
Не совсем понял как в принципе можно заменить у ВАС жесткий диск. Приходит на ум только колокейшн. Но это даже близко не облако. И даже не виртуализация.
Замена VHDX-файла на уровне гипервизора как вариант.
VHDX-файлы никто не передает от одного клиента к другому, их удаляют и создают новые. Такой прикол с чужими данными на новом диске возможен только для физического диска.
Хорошо бы естли Вы были правы. Человеческий фактор никто не исключал…
Замена VHDX-файла на уровне гипервизора как вариант.
+
Человеческий фактор
Разочарую ( не говоря уже про Shielded VM ):
Это просто неудобно выискивать где-то старый .vhdx/.vhd, переименовывать, перемещать в нужный каталог. ( Да и это всё придётся делать вне SC VMM)

.vhdx/.vhd c ОС ( «c диском C:»), как правило, template после sysprep

Да, кстати, новый .vhdx/.vhd при создании затирается «нулями»

Могут "экономить" и не затирать, это снижает нагрузку на схд.

Если не ошибаюсь, на SSD затирание нулями части диска вообще бессмысленно. Дофига умный контроллер не сразу пишет в тот сектор, в который просит система, а сначала переназначает этот сектор в наименее изношенные ячейки памяти.
на SSD затирание нулями части диска вообще бессмысленно
Да, от имеющего доступ к физическим дискам «затирание» защищает «не полностью». ( От «утечки» через физические диски — Shielded VM )
Но у нас случай «Замена VHDX-файла»
переназначает этот сектор
и внутри Hyper-V VM виден как раз переназначенный сектор
Такую «экономию» можно сделать только на уровне драйвера ФС хранилища, но никак не на уровне бестолкового админа.
«экономию»... на уровне бестолкового админа не сделать.
Я как раз об этом: что бы внутри Hyper-V VM на дисках один клиент увидел данные другого, надо что бы «ленивый» оператор приложил слишком много усилий. Т.е. это крайне мало вероятно.
А я что, спорю с вами?
Так и я Вас, лишь «дополняю» Ж-)
Разочарую: Это просто неудобно
Могут «экономить» и не затирать,
На всякий: «затирается нулями» автоматически при создании .vhdx/.vhd ( без этого — только утилитами «со стороны», а их, для начала, надо ещё и найти).
это снижает нагрузку на схд.
Для оптимизации — технология ODX (Offloaded Data Transfers)
Не хватает еще мифа — облако дешевле. Почему-то почти все облачные об этом говорят, хотя на самом деле надо считать…
Не хватает еще мифа — облако дешевле. Почему-то почти все облачные об этом говорят, хотя на самом деле надо считать…
в пересчете на час простоя очень может быть, с учетом того, что час простоя обходится вашей фирме в 100к$. А построить и содержать ДЦ уровня TIER III+ (а по хорошему надо хотя бы два ДЦ) могут позволить себе далеко не все.
договор с сервис провайдером включает компенсацию рисков простоя? Или как обычно, пересчитают абонентку за время простоя?
А вы видели, чтобы где то включало? Ибо 100% доступности вам никто не даст, хотя были прецеденты. Я лишь говорю о том, что хороший облачный провайдер, например, тот же амазон, сводит риски проблем с инфраструктурой к минимуму, но естественно не к 0.

Плюс надо «уметь готовить облачных кошек», как говорится в той шутке. Если рассматривать в контексте все того же Амазона, если вы разместили свое приложение в одной AZ и у вашей базы нет реплик, то естественно при проблемах с AZ в этом регионе — ваше приложение скорее всего будет недоступно. Но при правильной настройке инфраструктуры — выход из строя AZ уже не будет катастрофой. А стоит оно того или нет — тут уже надо считать и однозначного ответа нет.

P.S.
Так сказать по горячим следам. Переехали на Амазон. Я правда не совсем понял, как быть с вашим законом о персональных данных, но тем не менее.
Не надо говорить о стоимости простоя, если нет возможности его компенсировать. Уровни TIER III+ не нужны 99% компаний, даже более того, из 1% тем кому они нужны, обходятся без него.

Хорошим, сервисный провайдер, будет ровно до возникновения проблем. Если они готовы взять на себя финансовую ответственность — другой разговор, иначе это все пустой маркетинг.
Не надо говорить о стоимости простоя, если нет возможности его компенсировать.
но есть возможность свести его шанс к минимуму, что и делает TIER III+. Точнее это лишь один из пунктов. Не спорю там много и маркетинга, но вот как раз сертификация TIER не позволила бы запустить ДЦ с аплинками от одного провайдера, да еще и без BGP, как было в случае с Битриксом.

Уровни TIER III+ не нужны 99% компаний, даже более того, из 1% тем кому они нужны, обходятся без него.
откуда такая статистика?

Хорошим, сервисный провайдер, будет ровно до возникновения проблем. Если они готовы взять на себя финансовую ответственность — другой разговор, иначе это все пустой маркетинг.
не уверен что такое вообще есть. Ибо даже циски, которые стоят по 1кк ломаются и никто вам не будет компенсировать время простоя. Да у них есть саппорт, и они гарантируют, что произведут замену железа в течение N часов, но компенсировать вам убытки за эти N часов они не будут.
У меня в одной из компаний было три провайдера, пул своих адресов и bgp, но TIER III там нафиг не нужен был. И это был не сервис провайдер, а обычный жирный энтерпрайз. Циски не самое дорогое оборудование, и не самое стабильное.
Один из факторов почему ИТ-служба может саботировать переход на облака (неважно с начальником или без) — понимание того, что появляется новая ответственность (взаимодействия с провайдером), а из инструментов только хелп-деск и даже мониторинга нет. Невозможно даже узнать реально ли идёт работа с твоим инцидентом или просто в очереди он ждёт. А может им какой-то стажёр занимается. Есть впечатление, что от тебя что-то скрывают, например неопределенность. Кроме того, объективно время обработки инцидента увеличивается. in house специалист проводит исследование инцидента, определяет что проблема «на той стороне» и должен либо кратко сообщить «HELP!!! ничего не работает» с потерей времени на повторную диагностику, либо описать (читай — тратить время на описание)шаги и результаты диагностики, что бы in cloud специалист не тратил время га неё.
Простите, что повторяемся, но тут снова всё зависит от провайдера. Мы, например, не только в SD работаем, а еще постоянно на связи по телефону или через telegram. Мы информируем заказчика о статусе работ и часто работаем совместно с ним, помогая решать проблемы на границе ответственности. Наконец, заказчик всегда может попросить персонального СМ.

Статус — это хорошо, конечно. Как его проверить заказчику? Ну вот вы ему сообщили "диагностируем", потом "ищем пути решения", потом "пробуем решить". Как ему проверить, что вы уже реально пробуете решить, а не всё ещё диагностируете, не желая признаваться в том, что пока не знаете что происходит вообще? Даже внутри собственной ИТ-службы может быть подобное выдавание желаемого за действительное если нет непосредственного наблюдения за ходом работ. А тут практически "чёрный ящик".


P.S. Я ничего против вас не имею, лишь объясняю психологические и близкие к ним моменты ожиданий от облака. Если у вас абсолютная прозрачность, не знаю, экраны там с заказчиком расшариваете, трансляцию устных разговоров ведёте с рабочих мест, то вам надо это подавать как конкурентное преимущество.

Угадаете, где облако, и какие конкретно стойки относятся именно к вашим данным? И как их так вынести, чтобы не уронить чей-нибудь банкинг или ИТ госпредприятия? Отделить, где именно чье, физически невозможно.

Без обид, но увидев соответствующую бумагу, вы сами все вынесете, в коробочки сложите и бантиком перевяжете. Иначе привет вашему бизнесу.
Не правы Вы.
Когда человеки в масках приходят в офис, они сразу блокируют доступ к серверам, отрубают их и выносят. Вместе с данными.
Если данные в облаке, то даже если эти человеки знают об этом заранее и приходят не в офис, а сразу к провайдеру, то вынести серверы они не могут. Как и СХД. Просто вынести допустим 100 стоек вообще сложно да и там данные не только одной компании.
Итак нужно постановление. А бумажку нужно хотя бы просто прочитать. Потом дать команду найти данные. А пока их будут искать… Некие неустановленные лица могут войти на портал самоослуживания и удалить ВМ/стереть данные.
Мне конечно могут возразить, что данные можно восстановить с жесткого диска.
И мой ответ — нельзя. Потому что на одном диске хранятся данные сотен компаний. Именно так — куча маленьких кусочков разных данных. Причем чтобы от этого кусочка был толк его нужно соединить с еще сотней кусочков которые раскиданы не просто по другим дискам — а по другим полкам и даже устройствам. И вот стоит такая СХД размером в несколько стоек и объемом в фиг знает сколько петабайт, которую используют фиг знает сколько хостов виртуализации, на которых работают фиг знает сколько ВМ, принадлежащих фиг знает скольким компаниям.
И хостер любезно показывает логи, из которых следует что ВМ удалены пользователем.
Вот и все.
А если придут в офис, то опять же логин с паролем от портала самообслуживания нужно еще получить. Даже если поймают сисадмина, то пока его пытают его коллега/начальник который на выезде может зайти на портал и подчистить.
в наших реалиях, описанный вами сценарий будет очень рискован и как следствие «облако» просто отдаст данные и все
Собственно формат «вынести весь ДЦ из-за одного клиента» однажды был реализован на Украине.
Очень занимательно. Вот только все перечисленное слабо интересует пришедших с бумагой.
Не обеспечите, будете виноваты. Так что выдадите, никуда не денетесь.
Очень занимательно. Вот только все перечисленное слабо интересует пришедших с бумагой.
Не обеспечите, будете виноваты. Так что выдадите, никуда не денетесь.
Значит в вашем сценарии хостеру можно только посочувствовать. Однако проблемы индейцев шерифа не волнуют. Т.е. главное то — что организация свои данные врагу не сдаст, а как будет хостер опрадываться это уже другой вопрос.
Вы меня не поняли. Я не верю в такого хостера который свой бизнес ставит ниже интересов клиента.
Вы намекаете на то, что как только хостер получит бумагу он тут же заблокирует учетку арендатора чтобы тот не удалил данные?
да хостер сам будет максимально содействовать, чтобы не получить проблем на свою голову. Вот прям сами все принесут, сами скопируют данные, все сделают, чтобы все стойки не отключили.
Я говорю о том что когда хостер будет знать что за то что он не даст пришедшим то что они просят ему очень сильно за это скажут, то он и заблокирует, и все что угодно еще. Своя рубашка ближе.
Так то оно так. Но ведь изымающие могут и не сказать специально: «заблокировать все учетки». А инженер без команды сам может и не проявлять инициативу. Т.е. шансы то повышаются. А если данные очень ценны, то можно и на личный контакт пойти, не обязательно с руководителем. Так что и шепнуть могут при случае.
Как тут писали уже для приватности и пушку использовали. Так что в облаке данные можно уничтожить даже при наличии у администрации хостинга огромного желания сотрудничать. Я так думаю.
Понимаете.
Можно требования формально исполнить. Но когда ты знаешь что за это тебе будет ой, то это сильный стимул выполнять требования по существу.
Вопрос чем рискуешь.
Ок. Что конкретно будет тому руководителю/инженеру кто предупредил заинтересованных лиц?

Навскидку, УК РФ Статья 310. Разглашение данных предварительного расследования


P.S. Ещё УК РФ Статья 294. Воспрепятствование осуществлению правосудия и производству предварительного расследования

Разглашение данных предварительного расследования неустановленными лицами. Не, как-то не впечатляет. Вроде и есть наказание, а вроде и нет.
Вопрос неправильный. Что будет хостеру в целом.
Я повторюсь — проблемы индейцев шерифа не волнуют. Руководителю организации главное сохранить приватность своих данных.
Повторюсь и я. Владельцу главное сохранить свой бизнес.
Когда выбор меж потерять бизнес и сохранить приватность клиентских данных.
Выбор невелик.
Опять повторюсь — выдача органам имеющихся данных не всегда может зависеть от воли руководителя. В том контексте, что воля то есть, а данных уже нет. И нет тех, кто способствовал этому. Вернее они то конечно есть, просто их личности не установлены.
На одной из лекций преподаватель сказал: то, чему мы вас тут учим конечно важно, но не забывайте, что в большинстве случаев данные похищаются не путем взлома, а… приносятся на флешках.
Да. Воля есть а данных нет. Типа мы не виноватые.
Но фишка в том что тут вы не угадали. И обуют именно вас, за то что не обеспечили. А не могли или не хотели… кому это интересно. Дайте нам это, а как нас не сильно то и… бет.
Именно так, не виноватые. Нет данных — нет доказательств. Могли бы пришить что-то, так пришили. И не стали бы заморачиваться с обращением к хостеру, где лежат компрометирующие меня данные.
Есть обязанность — нет исполнения.
ВМ ведь бекапятся — так что и из бекапа достанут после удаления или получат много-много проблем и потерю репутации, когда погасят весь ДЦ. Рвение зависит от информации — если за одной стороны «могут шлёпнуть, чтобы не получили доступ», то и с другой черепашки-нинзя могут рубильник дёрнуть (и не один, а сколько потребуется) и руководство предпочтёт локализовать проблемного клиента, а не поднимать потом ДЦ и отвечать перед всеми, лишившимися доступа. И приходят одновременно в разные места — где мордой в пол, где вежливо просят содействия, но результат один — настоящих буйных мало.

Что вы лично, а не абстрактный камикадзе, сделаете?
Без патетики и теоретизирования.

С деньгами все очевидно: перенос инфраструктуры на облачного провайдера позволяет экономить. Это понимает почти каждый.

Вот очень интересно откуда берется эта прописная истина и кому она известна. И самое главное почему это понимает почти каждый?
В длительной перспективе облака дороже чем свой ЦОД. Это конечно зависит от объемов, но дела обстоят именно так. Вот статья о стартапах которые покинули облака
Облако безусловно выигрывает в легкости масштабирования вычислительных ресурсов ну и в переводе CAPEX затрат в OPEX
Мы практически с каждым заказчиком проводим расчёт ТСО. И почти всегда облачная модель выигрывает. Нужно понимать, что у провайдера есть точки экономии, которые заказчик, если это не огромная корпорация, просто не может получить. Например, специальные программы с производителями ПО, когда его можно получить по подписке. Или стоимость оборудования, которая у нас ниже. Или построенные процессы и большой объём, которые снижают стоимость эксплуатации. Если хотите, можете скинуть нам свои данные на почту team@ts-cloud.ru, а мы в ответ пришлем такой расчет.
А вы точно про экономию в общем, а не про переносе затрат из opex в capex?
Всегда умиляет такие рассуждения про экономию… 90% мелких компаний в России меняют оборудование только когда оно выходит из строя. Да и у средних с этим не все гладко. По факту плата за оборудование в офисе выходит процентов 10 от платы за облако в год. А админу все равно платить.
Дешевле только если учитывать полную стоимость оборудования. У нас тут как-то сервер умер — задумались об облачном. Посчитали стоимость и купили новый. Примерно в годовую плату за облако обошелся. Учитывая что в компании сервера лет по 10 стоят…
Это как раз производство и не Москва. А мелкие торговцы и вовсе почти всегда назначают серверами обычные офисные системники.
Подпишусь под каждым словом. Цена за год аренды выделенного = цена за новый сервер. Реальная эксплуатация подтверждает, что в бизнесе сервера в среднем живут около 10 лет. А значит экономически выгоднее пока что собственная инфраструктура. И никакие «облака дешевле» не прокатят для тех кто ещё в силах посчитать.

Согласен. Из опыта сервера живут до физической поломки материнки или чего-то подобного. Серверов не много было, но срок службы до крупной поломки порядка 8 лет и более. На уровне 10 лет уже ничего живого на 100% не осталось. Было и есть несколько офисников в роли серверов, на удивление отхаживают не на много меньше (недавно снял накопитель 7,5 лет в работе 247365, смарт очень даже живой). Сколько это стоит в офисе и сколько будет стоить в облаке что-то подобное? Облако явно дороже.

Согласен. Главное преимущество облака — это как раз защита от изъятия оборудования.
Даже российское облако в этом плане дает защиту — пришедшие органы пока разберутся что и как (а могут и не разобраться, если вы услуги облака не со своего счета оплачиваете), вы свои виртуалки мигрируете.
А это идея! Приходит полицейский в ДЦ, а его коллега у магистрального провайдера смотрит, по какому айпишнику исходящий трафик внезапно поднялся )

Этот миф сами облачники и пытаются создать

Это миф может если вы Навальный. А если вы обычный бизнес, и к вам приходят обычные менты, то сомневаюсь, что они в принципе найдут в каком дц у вас сервера.
Средний и малый бизнес предполагает, что, когда придут проверяющие органы, самое безопасное — это кладовка, где стоит стойка, а рядом кипит чайник или лежит пожарный молоток. Дальше сервер заливается водой, или жёсткий диск разбивается в клочья. Мы в таких случаях просто показываем 30 машзалов, в каждом — 100 стоек. Угадаете, где облако, и какие конкретно стойки относятся именно к вашим данным? И как их так вынести, чтобы не уронить чей-нибудь банкинг или ИТ госпредприятия? Отделить, где именно чье, физически невозможно. А изъять все и сразу — инцидент национального масштаба. А ещё, даже если вдруг кто-то всё изымет, из оборудования, которое ты вытащил, ещё надо собрать что-то работающее. И это, скорее всего, не получится

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

Опять же нужно знать где та кладовка. Собственный километр-другой оптики стоит не так дорого )

а что мешает «пойти» по оптике? тогда уж wifi канал настраивать.
Глухая стена?
С деньгами все очевидно: перенос инфраструктуры на облачного провайдера позволяет экономить. Это понимает почти каждый.

вот бы свести вас с продажниками vmware, запастить попкорном и посмотреть на это "действо" ;))

Многие пишут про стоимость серверов.
Но предлагаю подумать про стоимость потери данных и стоимость простоя. На западе это один из ключевых критериев. А не «у нас упал сервер и мы подумали о переходе в облако».
согласен, нужно считать стоимость 2х серверов. Да и сервера обычно падают по сфотварным причинам, чем по физическим.
Есть Hyper-v кластер, есть бэкапы виртуалок — все это без проблем работает на обычных компьютерах в офисе.
А мужики то не знают. Зачем то покупают ту же vmware, да при этом в максимальной редакции. Про какую-то репликацию еще говорят. Серверы еще, вместо того чтобы обычные компьютеры использовать. Короче тратят деньги почем зря.
Можно объективно, по пунктам, чем вмваре лучше хипер-в?
Наверное из-за того что не мастдай (сарказм)
Одним только тем, что выбирая гипервизор «не мастдай» — вы убираете часть своей инфраструктуры с пути наиболее распространенного вектора атаки хакеров.
Сарказм ли?
Еще бесплатность ESXi-а добавьте.
Не добавлю.
Он очень даже платный.
В бесплатных версиях отключено очень много полезного функционала.
Ключевое слово — бесплатный, а но то, что нет функционала это уже второ- если не третестепенно для шараш-монтаж конторок. Тут уже действует золотое правило — фигак-фигак и в продакшн (мат завуалирован)
Сравнивают платформы виртуализации в контексте «лучше-хуже» по моему мнению либо сами вендоры, либо те, кто работает с какой-то одной. Я работаю с тремя. И просто оперирую понятием «сильные и слабые стороны», «целесообразность» в каждой конкретной ситуации. И факторов, влияющих на выбор, очень много.
Вот пример. Есть удаленный офис. Помещение, где стоит сервер, не оборудовано системой кондиционирования, железо сервера не мониторится, местного админа либо нет либо бывает редко. О чем в первую очередь нужно задуматься?
Это практический вопрос.
( Положим, кондиционер «стоит денег»
железо сервера не мониторится
Но что мешает установить агента системы мониторига? )

удаленный офис. Помещение, где стоит сервер, не оборудовано
Q: О чем в первую очередь нужно задуматься?
A: задуматься надо о том, что мешает работать по RDP на мощностях головного офиса?
Но что мешает установить агента системы мониторига? )
агенты? куда это вы их ставить собрались?
А о чем стоит задуматься, так это о том, что,
Во-первых: если что с хостом/хостами случится, то устранение проблемы может занять значительное время (в связи с отсутствием в момент сбоя админа).
Во-вторых: это жесткие диски. При повышенной температуре они дохнут гораздо чаще. В случае с СХД можно использовать (и даже нужно) spare — поставить как на RAID так и на всю СХД, в зависимости от типа СХД конечно же. Но если умрет диск, даже если он в зеркале, на котором стоит ОС гипервизора, то все может оказаться очень грустно. Что делать?
Var A
На небольших филиалах сервера просто не нужны:
удаленный офис. Помещение, где стоит сервер, не оборудовано
Q: О чем в первую очередь нужно задуматься?

A: задуматься надо о том, что мешает работать по RDP на мощностях головного офиса?

Var B
«Сервер на филиале» есть
( Лирическое отступление:
железо сервера не мониторится
VVM>>> Но что мешает установить агента системы мониторига?
агенты? куда это вы их ставить собрались?
Агенты, к примеру, MS OpsMgr есть и под Win, и под Linux. Датчики температуры есть и в оборудовании CISCO )

Q: умрет диск, даже если он в зеркале,.. ., то все может оказаться очень грустно. Что делать?

Использовать Starwind HA, тот узел где идёт перестройка RAID
на время отключать от соседа
( Рискну и напишу, то что делал бы на самом деле)
... платформы виртуализации в контексте «лучше-хуже»...
Я... оперирую понятием «сильные и слабые стороны», «целесообразность» в каждой конкретной ситуации....
Вот пример. Есть удаленный офис. Помещение, где стоит сервер, не оборудовано системой кондиционирования, железо сервера не мониторится, местного админа либо нет либо бывает редко. О чем в первую очередь нужно задуматься?
Это практический вопрос.
возвращаясь к вопросам выбора ESX/Hyper-V: конкретно в этом случае, Windows c GUI.
Т.к. для него реально обучить не-IT работников делать shutdown.
Да, кстати, сервер придётся из кладовки вынести
Какой Starwind HA, какая перестройка RAID, какой сосед.
Я же конкретно пишу про диски, на которых стоит система.
Ладно если хостов два. А если он один? Сначала умер один диск, потом, через месяц или больше второй. И никому дела нет что диск красным уже месяц. От слова: «пофигу». При наличии системы мониторинга она сама шлет алерт, и уже через часы перед вами стоит курьер службы доставки с новым диском. Но системы мониторинга нет. Потому что, как я уже сказал «пофигу».
И даже при наличии всяких там соседов никто никого отключать не будет, потому что некому. И также некому будет откатывать обновления, если после них винда начинает работать не корректно. Да и не только в обновлении дело. Ток отрубили, ИБП нет, все легло. И после хост с Hyper-V не поднялся.
Вы думаете нет таких филиалов и не только филиалов?
Они есть и их много. И вот в таких случаях моя позиция — никакие Hyper-V.
А вот если в организации используется system center — то может быть и нет смысла замарачивается настройкой системы мониторинга от вендора железа. Дело это муторное на самом деле и требующее определенных познаний. И да, Hyper-V оптимальное решение.

Я же конкретно пишу про диски, на которых стоит система.

Если что, подъем хоста Hyper-V с нуля взамен упавшего — дело 5-10 минут щелканья кнопками в стиле next-next-next, получаса установки, ну и еще полчаса на аттач виртуалок и проверку, что всё поднялось.


Ток отрубили, ИБП нет, все легло. И после хост с Hyper-V не поднялся.

Это крайне маловероятная ситуация. Говорю в том числе из практического опыта, у нас энное количество хостов годами работало, регулярно вырубаясь из-за проблем с электропитанием в силу некоторых особенностей региона и бизнеса. За, наверное, неколько сотен вылетов по питанию сдохло две или три виртуалки и ни одного хоста.


Не надо преувеличивать проблемы. Когда за неимением гербовой приходится писать на простой, часто оказывается, что этого вполне достаточно. :)

Давайте определимся с численностью работников нашего условного филиала...

Например, на небольшом филиале:
ИБП нет
UPC обычно есть, но со с батареями более 3-х лет

GoTo
работать по RDP на мощностях головного офиса

на головном ( и на крупных филиалах) батареи в UPS мы таки заменим...

P.S.

Какой Starwind HA, какая перестройка RAID, какой сосед.
Я же конкретно пишу про диски, на которых стоит система.
Загружайтесь по iPXE c iSCSI
И также некому будет откатывать обновления, если после них винда начинает работать не корректно.
Наслышан, но, наверно, «что-то делаю не так»
Ни разу в жизни не приходилось ничего откатывать
( WSUS Security + Critical)
Ток отрубили, ИБП нет, все легло. И после хост с Hyper-V не поднялся.
А с ESX поднялся? И даже VM целы?

P.P.S. Про «мониторинга от вендора железа» беру timeot на обдумывание ( + см. в «Диалогах» надо уточнить детали )
Реально устал.
Sorry, не хотел в пятницу на столько уж «озадачивать»...
Всё о чем писал ( кроме iPXE) «испытано на себе». Можете «брать на вооружение», а не подходит к конкретной ситуации — «забыть как страшный сон» Ж-)
Отмечу что у Hyper-V тоже есть бесплатная редакция =)
Предлагаю не вестись на провокации и не уходить от темы статьи в сторону обсуждения конкретных гипервизоров. И опять же предлагаю подумать над техническим решением вопроса «удаленный офис».
Один из вариантов — это конечно перенос нагрузки в облако (частное, публичное — не суть важно в данном случае). Но хочется услышать еще варианты.
Hyper-V да, бесплатна, но серверное ПО, в частноти MS Windows, не бесплатен от слова совсем.
Есть же бесплатный Core, на котором hyper-v прекрасно работает
Спасибо, не знал, что «корка» бесплатная. Особенно поразило, что на неё можно «натравить» GUI консоль от другой машины и управлять как GUI-Hyper-V.
Смотрите-ка, упоминаешь что есть бесплатная версия у продукта — и сразу -1 =) Мне с моей кармой в принципе не страшно, но хочется узнать мотивацию.
Чем проще гипервизор — тем он лучше, а Windows — это очень сложная система. Петя это еще раз доказал.
Не совсем удачное сравнение, но кто захочет, идею поймет. Кто не захочет — тому хоть колом на голове чеши.
Итак стоят мужички, в резиновых сапогах, и чувак в костюмчике им рассказывает чем его мерседес лучше их нивы. Они выслушивают, а потом говорят: океюшки. Что-то мы не запомнили всего, давай съездим на рыбалку, там еще раз расскажешь. А дело весной было…
Но этот чувак дурак не потому, что купил дорогую машину, а будет дураком, если по бездорожью поедет на мерседесе.
И многие компании имеют в своей инфраструктуре разные гипервизоры. И когда до них кто-то докапывается и требует объяснить чем это используемое ими решение лучше просто посылают лесом.
Во многих случаях сложность винды компенсируется наличием большого числа специалистов, знающих как с ней обращаться. По сравнению например с Open Stack.
А если люди в город, тем более большой, выбираются раз в квартал, то кроме нивы или уаза им вообще то и не нужно ничего.
Во многих случаях сложность винды компенсируется наличием большого числа специалистов, знающих как с ней обращаться.

Даже в теории звучит как нонсенс: чем сложнее система, тем больше людей знают её.

Не очень понимаю при чем тут виндовс. Есть Hyper-V сервер, который ставится на голое железо и у него, вроде, даже гуя нет. Гостевой системой там опять же может быть что угодно. Каковы критерии сложно/просто в контексте гипервизоров?
Большинство ставят именно виндовс с ролью. Потому что, как я уже сказал, windows широко распространена и специалистов по ней много.
Чистый Hyper-V ставится сложнее, но сам он проще. Проще в том плане, что меньше всяких ненужных сервисов, меньше вероятности что он упадет при очередном обновлении.
А вот довод «чем сложнее система, тем больше людей знают её» — это искажение смысла высказывания.
Windows Core это неотъемлемая часть Hyper-V Server и как минимум протокол RPC(tcp/135) у него реализован.
>>>Чем проще гипервизор — тем он лучше, а Windows — это очень сложная система. Петя это еще раз доказал.
>>при чем тут виндовс?
>Windows Core это неотъемлемая часть Hyper-V Server и как минимум протокол RPC(tcp/135) у него реализован.
( Мне почему-то кажется, что Петя использовал скорее SMB чем RPC )

1) Предлагаю, всё-таки, сравнивать ESXi с Nano Server
( про то, что MS сделал шаг назад ( «только контейнеры») в курсе,
но Nano из поставки Win Server 2016 для Hyper-V «пригоден» точно).
Или если с Core, то с Core как следует настроенным.

2) Какая Вам польза от уцелевшего хоста ESX, но c «уничтоженными» VM?
( и, допустим, с устаревшими backup копиями?)

Т.е. защитить «машины с Windows» от Пети придётся всё рано и при ESX, и при Hyper-V
Польза от живых гипервизоров в момент Ч есть и огромная т.к. сокращается время восстановления. А ведь гипервизор это то что надо ставить ручками на голое железо и если нет KVM(ilo) — большой кусок работы.
Петя вроде да, ходил через SMB. Про RPC я написал т.к. все равно в нем есть и будут уязвимости и MS будет патчить эти уязвимости, а эти патчи придется накатывать и лишний раз перезагружать гипервизор.

Про устаревшие бекап копии давайте не будем, это отдельная тема. Но скажу так — есть гипервизор и есть бекап = 95% проблем решаемые в ситуации полного цейтнота.

Про Hyper-V на нано сервере ничего не слышал к сожалению.
А ведь гипервизор это то что надо ставить ручками на голое железо и если нет KVM(ilo) — большой кусок работы.
просто процитирую:
Если что, подъем хоста Hyper-V с нуля взамен упавшего — дело 5-10 минут щелканья кнопками в стиле next-next-next, получаса установки, ну и еще полчаса на аттач виртуалок и проверку, что всё поднялось.
Петя вроде да, ходил через SMB. Про RPC я написал т.к. все равно в нем есть
Входящий SMB по умолчанию заблокирован. ( RPC — по памяти не скажу)
патчи придется накатывать и лишний раз перезагружать гипервизор.
Решаемо: сделайте Hyper-V кластер и перезагружайте хост за хостом Ж-)
Как-то на собеседовании у меня спросили: как можно удаленно диагностировать проблему сервера/просто зайти если он не доступен по сети? Всякие IPMI говорю, типа iLO у HP и iMana у Huawei.
Тогда я подумал: что за элементарные вопросы такие.
Мда, если используются обычные компьютеры то вопросы совсем не элементарные. Век живи век учись.
Если используются обычные компьютеры, то удаленная диагностика не нужна. Админ сходит и посмотрит, если сервер сломался, то просто восстановит виртуалку на резервном компьютере.
Админ сходит и посмотрит

Вот и руководство так думало. Поэтому когда балансодержатель проводил всякие работы с электричеством нас держали на работе. Весь отдел.
Но опять же мы не бегали как жучки по этажам и серверным включая питание. А спокойно сидели в кабинете и заходя на iLO жали кнопочку. Да и по выходным проводя регламентные работы или апгрейд находились дома.
К хорошему привыкаешь быстро. Поэтому про «обычные компьютеры» умом понимаю, но психологически принять все равно не могу.
Я про малый бизнес, если у вас целый отдел и много серверных, то вряд ли в качестве серверов используются обычные компьютеры.
Хотя, насколько я помню, и в старших моделях i7 есть что-то для удаленного управления.

Вот только для многих дешевое купить системник за 40 килорублей и дать сисадмину на такси 500р в выходной, и то пару раз в год, чем купить правильную железку с удалённым управлением за 180-200 тысяч. Задачи у всех разные.

У меня на прошлой работе зам. министра постоянно с собой ноут возил в машине. И бывало из ягипта админил. А другой руководитель поста лишился. Из-за сбоя.
Случаи да. разные. А железка дешевле 300 и не стоила, к слову…
Парадокс. За несколько лет могу пересчитать на пальцах одной руки случаи, когда клиент мог сказать нагрузку своего виртуального кластера. Можно ли быть эффективным в том, что даже не измеряешь?

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

Хотя может быть это survivor bias. И те, у кого все грамотно в собственной инфраструктуре просто не обращаются к облачным провайдерам.
Для малого бизнеса виртуализация нужна не для повышения утилизации, а для упрощения резервного копирования и сокращения времени простоя. А сервера так и стоят недозагруженные, зато можно за несколько минут поднять копию виртуалки на втором сервере, в случае поломки основного (даже без кластера).
В случае малого бизнеса как раз может быть эффективней взять виртуалки в том же Amazon или что-то поприличней в России. Главное понимать, что и зачем берешь. Только если в бизнесе стоит 2 б/у то и сравнивать надо с low-cost хостингом на таком же б/у.

Мои кейсы все не про малый бизнес.

Кстати, про сравнивать и б/у. Сегодня прибегает очередной продавец с круглыми глазами — «Как так у нас VMware на Xeon E5 v4 дороже, чем KVM на ProLiant G5? Как такое может быть!? Непорядок!». И в большинстве случаев клиент только на ценник и смотрит, особенно из организаций поменьше. Хоть что ему объясняй. А потом будет удивляться, что лежит пол дня по 4 раза в месяц у этого горе хостера.
Я сравнивал. Пара серверов (которые обычные десктопы на i7\64gb\ssd) в моем малом бизнесе работают 7-й год, куплены за 2500$ за оба, на них крутятся виртуалки с 1с (для которой большое количество памяти и ssd обязательны). Какой low-cost хостинг даст сравнимую производительность за эти деньги?
В этом случае я бы рекомендовал смотреть на dedicated server на западных площадках, типа дочернего проекта OVH
www.soyoustart.com/ie/game-servers — выйдет, конечно, дороже

Далеко не везде критично падение на пару часов. Где критично, будут систему уже посложнее.

Так умер один из. Все содержимое успешно мигрировало на другие и спокойно (ну или не очень, из-за возросшей нагрузки) работало до приобретения нового.

Не факт, что простои со своими серверами будут больше чем с облачными. Насчёт потерь данных — очень много нюансов. В любом случае нужно самостоятельно заботиться о создании бэкапов в географически и юридических разнесённых точках.

Если есть свои грамотные спецы и развитая инфраструктура, то как вариант — гибридное облако.

Вот я не понимал зачем нам на прошлой работе было нужно гибридное облако. Своё по ощущениям работало надежнее.

Дело не в надежности. Один из вариантов — резервирование. Чтобы не создавать самим удаленную площадку. Либо при наличии регулярных пиковых нагрузок. Например на всех хостах у вас память по максимуму. Но иногда ее не хватает. Можно либо купить еще хост с лицензией, и набить его памятью, либо на существующем заменить 16 Гб на 32 Гб, но не на одном а как минимум на двух. Либо гибридное облако.

Не наш сценарий. Была своя стойка, в которой было своё облако, и были ресурсы облачного провайдера. Сценарии оперативной миграции не отрабатывались. То есть если резервирование и имело место, то где-то "в уме", максимум на уровне разговоров "в курилке": если упадёт один из ДЦ, то мы виртуалки из бэкапов перетащим.

Вместо 1000 слов, почему бы Вам тупо не привести подробные расчеты по которым Ваше облако выгоднее чем шкаф. Например, для 50 и 100 виртуальных машин с резервным ЦОДом и без него.
Если принюхаться к статье, попахивает маркетингом. Особенно огорчает отсутствие статистики или конкретных кейсов. Плохо.
попахивает маркетингом.


Серьёзно? Статья в корпоративном блоге пахнет маркетингом?
Не, не может быть, вам показалось.
Всё таки хотелось бы верить, что статью написал сам руководитель бла бла бла, а не маркетолог. Жаль, что желания не всегда совпадают с возможностями.
Имея смелость довести все эти рассуждения до их логического конца, можно прийти к мысли, что вообще маленькая компания неэффективна и её надо сделать частью большой корпорации. Зачем ограничиваться только ИТ?
По сути так и есть, ИТ, Бахгалтерия, Маркетинг — всё в аутсорсе у многих мелких контор.

Тут скорее противостояние не "маленькая-большая", а "специализированная-широкого профиля". Навскидку может получиться даже, что выделение существующего подразделения в специализированное дочернее юрлицо увеличить суммарную эффективность (вне рамок налоговых оптимизаций). При условии, что "мама" не будет осуществлять микроменеджмент "дочки".

В том году считали: собственный сервер, в сравнении с облачным, с однотипными показателями окупается за 16-18 месяцев (менее двух лет). Срок эксплуатации сервера — 5 лет. У нас уже есть старички по 10 лет. Вопрос, насколько выгоднее своя инфраструктура, если учесть, что сервер почти не требует никакой поддержки (реально у нас за семь лет вышло всего три диска (тьфу, тьфу, тьфу)).

Вопрос о критичных и финансовых данных. Если честно, то как и бэкапов — их нет в офисе. Вообще. Более того, что все параметры VM известны и в случае апокалипсиса сможем развернуть, как написано было выше, даже на машине сотрудника.

Критичен ли нам полный простой в течение пару часов? Нет. У многих есть с чем работать и так.
Всегда найдется в компании из 20 с половиной сотрудников какой-нибудь бизнес-девелопер, которому файл север нужен 365*24*7, не важно нужен ли он реально в таком режиме или нет.
Наблюдая за то как сборочные машины работают по ночам и коммиты прилетают среди ночи — тут вопрос такой неоднозначный. Другое дело, что загруженность ниже, но в пересчёте на то, что покупается, если покупать именно мощности, получается, как ни странно, дороже. Великая сила маркетинга.

ЗЫ: у меня самого дома стоит домашний сервер, который мне обошёлся в 16 тысяч рублей в 2015 году. На сейчас он не только окупил себя с точки зрения размещения на каких-то мощностях, но и принёс прибыль (коммпроекты крутятся с небольшой загрузкой). Ещё огромный плюс, что доступ к данным происходит на скорости около 800 МБс.

По поводу залить кипятком или рубануть топором.


Крупное производство, середина 2000-х. Нужно было обезопасить базу черной 1С. Поставили на харды электромагнитную пушку, а дистанционный брелок управления отдали гендиру и его персональному ассистенту.
Штука работает как часы, проверено — так как брелок очень напоминает брелок от автосигнализации, однажды его перепутали. Харды спалились, рабочая черная база улетела.
Хорошо был резервный сервак где-то в складских помещениях, под крышей, в очень секьюрном месте, всего один человек на фирме знал локацию. Вот с него и восстановили черную базу, а персональному ассистенту (которая брелки перепутала) седины прибавилось.

Поставили на харды электромагнитную пушку, а дистанционный брелок управления отдали гендиру и его персональному ассистенту.

Вашу пушку в серию пустили не так давно ;-)
не реклама
Этой пушке лет так несколько под ласково-отпускным названием «Прибой». Что-то на море захотелось даже. Стоил он около двухсот долларов тогда.

А вообще, по-хорошему, критичные базы не должны храниться в офисе. Равно как и сервер бэкапов, желательно, иметь вообще не там.
всего один человек на фирме знал локацию

Очень чревато.

Да, наверное всё же не один. Генеральный тоже был в курсе.
В случае гибели этого одного делается просто новый сервер в новой подсобке, про который знает новый «один»

А потом тщательный обыск и на руках у "органов" десяток живых реплик :)


Или ещё вариант, подсобка сдаётся/продаётся вместе с серваком, и новые эксплуатторы её обнаруживают и сдают в полицию как безхозную находку :)

Уолтер и Джесси из «Во все тяжкие» одобряют Вашу методику.
Еще до истерики с Meltdown я не доверял изоляции данных в облаке. А теперь…
Когда вам придет счет из Google Cloud (AWS/Azure/you_name_it) c едва ли не погигабайтной оплатой исходящего трафика, например, в Китай, тогда и поговорим.
Можно, конечно, сказать, что Китай — не наш целевой рынок и правилами заблокировать туда трафик, но достаточно 1 клиенту (или, что вероятнее, топу) оказаться в Китае, и вы будете ужом извиваться на каленой сковороде и объясняться, какого фига вы это сделали. Ну или объясняться, какого фига у вас перерасход средств. Ситуация lose-lose все равно.
Хорошая статья. И в комментариях лично я убедился, с какой неграмотностью можно столкнуться.
Вы заложили в проект стоимость серверов, схд (в том числе лицензии для репликации), стековые коммутаторы, систему кондиционирования и пожаротушения, СКД, лицензии System Center?
А вот у меня есть знакомый, у которого Hyper-v кластер работает без всяких там VMM, есть бэкапы виртуалок — все это без проблем работает без серверов и без репликации, на обычных компьютерах в офисе. И я ему не смог объяснить чем система кондиционирования лучше форточки.
Довод что серверные то не должны иметь окон, а ЦОДы вообще находятся под землей — ни для него, ни для его коллег — ни разу не довод. У них же форточка… И все работает.
При сравнении стоимости собственного сервера и облачного сервиса надо еще учесть стоимость потребления електричества собственного сервера, стоимость кондиционеров для его охлаждения и их елекропитания, стоимость построения той же серверной, которую в случае переезда компании часто надо бывает строить заново в новой локации.
По поводу фразы, что клиент рискует бизнесом, а провайдер облака клиентом… еще надо посчитать риски клиента в случае содержания собственной команды администрирования, особенно в случае небольшой компании с текучкой.

спасибо за статью, очень хорошо написана!
Плюс есть финответственность на уровне SLA

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

Если бы вы были «Корп софт» и из-за вас на 3 дня упал Битрикс24, вы бы им оплатили маркетинговую компанию для поддержания репутации?

Угадаете, где облако, и какие конкретно стойки относятся именно к вашим данным? И как их так вынести, чтобы не уронить чей-нибудь банкинг или ИТ госпредприятия? Отделить, где именно чье, физически невозможно.

Да вы сами все данные отдадите когда попросят, сделаете из «облака» обычный HDD и отдадите.

Что-то маркетологи ваши перестарались в статье… перегнули.
Да вы сами все данные отдадите когда попросят, сделаете из «облака» обычный HDD и отдадите.

Святая простота.
А данные будут лежать и дожидаться когда их отдадут.
вот один бы пример лучше привели, когда хостер рискуя свои бизнесом делал подобное. 100% отключит сервер от сети, чтобы не могли удалить данные и поможет скачать все что попросят.
Кстати, у меня есть готовый, проверенный на своей шкуре ответ на развенчание мифа от представителя провайдера:
Мы в таких случаях просто показываем 30 машзалов, в каждом — 100 стоек. Угадаете, где облако, и какие конкретно стойки относятся именно к вашим данным? И как их так вынести, чтобы не уронить чей-нибудь банкинг или ИТ госпредприятия? Отделить, где именно чье, физически невозможно.

… но органам не особо и нужно. Когда-то в датацентр, где было наше оборудование, приехала полиция изымать сервера одного предприятия, которые им надо было, извините за тавтологию, изъять. Так они первым делом вынесли весь датацентр, не заморачиваясь, кто там банкинг, а кто там госпредприятие. А потом в течении нескольких месяцев возвращали обратно. С тех пор я считаю, что хранить важные данные в любом отечественном датацентре не стоит.
я уже пальце стер доказывать, что так и будет, случись что. однако пару человек упорно доказывают, что костьми лягут что-бы бы сохранить данные клиента, вот прям завтра бизнес свернуть, но клиенты это святое.

Это или махровые маркетологи с заучеными сестрами или теоретики ни разу не сталкивавшиеся с такой ситуацией

Ну во-первых насколько я понял никто и не доказывает, что провайдер костьми ляжет. Это ваш максимализм. Потому что вы не видите иного пути как провайдер может сохранить данные, или вернее приватность клиента. И все доводы ваших оппонентов сводите к одному.
Теперь к вопросу почему вы не видите других вариантов.
Ваши цитататы
нужно считать стоимость 2х серверов
. Ну то есть 2 сервера — это тот же уровень отказоустойчивости, что может обеспечить облако. Если я правильно понял.
И вы даже не задумываетесь про другие аспекты, которые тут были озвучены мной и другими. В частности что дублировать нужно не только серверы, но и СХД (а лицензия, позволяющая делать репликацию платная) и коммутаторы. Серверная должна просто быть, т.е. помещение, отвечающее требованиям, плюс кондиционирование, СКД, ИБП. А если данные шибко критичны то и дизельное топливо. Для генератора. И сам генератор, который будет питать не только серверы, но и ту же систему кондиционирования. И контракт на поставку топлива — хоть ночью. И охрана нужна, которая цистерну запустит на территорию. И персонал, который зальет топливо в баки. И стоимость электричества. И еще много чего о чем я не знаю поскольку не являюсь специалистом в данной области.
И я не задумывался обо всем этом, когда у меня была маленькая такая контора на 50 человек. И когда серверы стояли со мной в одной комнате. И для меня тогда, также как и для вас отказоустойчивость ограничивалась двумя серверами.
Вторая цитата:
вот один бы пример лучше привели, когда хостер рискуя свои бизнесом делал подобное. 100% отключит сервер от сети, чтобы не могли удалить данные и поможет скачать все что попросят.

И она говорит о том, что вы даже близко не представляете как работает виртуализация вообще и облако в частности.
А по поводу реального случая, когда вынесли весь дата центр — хотелось бы узнать когда это было, и сколько стоек насчитывал ЦОД.
Что-то мне подсказывает что это было очень давно, и стоек было очень мало.
Сейчас чисто теоретически могут вывезти весь ЦОД, затратив пару недель, если не больше, и кучу денег на транспортные расходы. Но это чисто из вредности. Ибо как я уже говорил, прошли те времена когда данные хранились локально. На серверах. Сейчас они распределенные. И если при сборке ошибиться хоть на один кубик, ничего не заработает.
Но если все же потратили еще кучу денег на оплату труда инженеров (своими силами не справиться однозначно), и все заработало, то искать нужные данные… Если опять же своими силами то там уж срок привлечения к уголовной ответственности истечет. Да и обвинение предъявлять нужно, либо отпускать.
Так что вывоз не вариант
1. В этом же сообщении ниже пишете (не на прямую), что при угрозе отключить все стойки не отдадите данные клиенты. Во-первых я не верю, во-вторых считаю, что это и есть «костьми лечь»

2. 2 сервера у разных провайдеров покроют 99% всех требований. Я согласен, что есть задачи которые лучше решать в облаке, например быстрорастущие стартапы, они просто физически не смогут сделать лучше чем облако. Я лишь говорю, что таких задач не много.

3. Собственно и выносить нечего не надо будет, вам пригрозят, что выключат все ваше оборудование и не спеша будут выносить, после этого вы все и отдадите и поспособствуете и даже подскажете как данные вытащить. А учитывая наши реалии, могут найти что-нибудь запрещенное в серверной, чтобы еще сговорчивей стали.
Тут так уверенно обсуждают бумажку об изъятии, как будто все видели ее несколько раз и досконально знают юридические тонкости ее трактовки. Для безграмотных — можно хотя бы глазком на пример глянуть?
бо как я уже говорил, прошли те времена когда данные хранились локально. На серверах. Сейчас они распределенные. И если при сборке ошибиться хоть на один кубик, ничего не заработает.

Вы исходите из тех предпосылок, что полиция ставит целью что-то с тех серверов извлечь :)
Нет, они не собирались восстанавливать у себя весь датацентр (он был небольшой, не 30 машзалов. Один машзал, где-то «на глаз» сотня стоек, т.к. я по рядам там не ходил, не пересчитывал).
Они вывезли оборудование на склад, и там оно и валялось. Насколько я знаю, фирме-«виновнице» его тоже вернули, даже не притрагиваясь. Разница лишь в том, что нам это сделали бесплатно, а им пришлось делиться с так сказать, служителями Фемиды.
Более того, я вам расскажу эпизод про «маски-шоу» в компании, где я работал. Забежали мужики, всех выгнали с рабочих мест, далее их ИТ-эксперт сел перед моим компьютером, и глядя на окошко ввода пароля, изрёк: «У них все компьютеры соединены в единую сеть. Как у нас. База может быть где угодно». Рассказать ему про облачные технологии, и что, кхм, «база» находится на виртуалках где-то в Германии, я не рискнул. Боялся, что мозг может перегрузиться. Так что не рисуйте себе в представлениях крутых киберполицаев. Оперативники за последнюю четверть века не слишком поменялись в плане ИТ-подготовки.
Часто заказчик приходит и говорит, что у него важные данные. И ему нужна аттестация по определённому классу. Например, по 1К. И выкатывает требования для такой инфраструктуры. Во-первых, 1К не используется много лет. Во-вторых, вполне может оказаться, что у него данные третьей категории, и просто он об этом не знает, потому что кто-то либо некомпетентен, либо не умеет правильно оформлять документы, либо решил перестраховаться. Бывает, что юрист вооружается набором мифов и их уверенно отстаивает.

Ну и где тут миф? Во-первых, почему Вы решили что систем (не данных, у данных/информации по 17 приказу ФСТЭК бывает только уровень значимости, а по ППРФ 1119 нет классов есть категории УЗ-1 — УЗ-4) К1 (а не 1К) не бывает? Во-вторых, «Уровень значимости информации определяется степенью возможного ущерба для обладателя информации (заказчика) и (или) оператора» а значит не Вам решать насчет класса ИС. Ну и в третьих расскажите как у Вас дела обстоят с классами К2 и К3?
У нас есть Гос-Облако, инфраструктура которого аттестована по К1, то есть требования к системам классов  К2 и К3 выполняются… Есть Бизнес-Облако, оно не аттестовано по К1, но позволяет размещать системы персональных данных УЗ-3 и УЗ-4. На счет 1К — сорри, опечатались, тут имелась ввиду аттестация информационных систем персональных данных класса К1. Данная классификация была введена трехглавым приказом 2008 года, который ныне не действуют. Но частенько встречаются заказчики, которые, несмотря на то, что прошло много лет, не знают, что классификация ИСПДн изменена. Единственное, в этом же приказе вводились четыре категории ПДн, о которых мы и пишем. Теперь ПДн так не категорируются.
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.