Pull to refresh

Comments 49

Согласно заявлению разработчиков, избыточное тепло может быть отведено с помощью байпаса, а также может быть отдано наружной среде с помощью повторного охлаждения.
With the combination of Cloud&Heat with an air handling system, the heat not required in summer can be transported out of the building via a bypass. Cloud&Heat adapts the heat output to the building itself in accordance with the heat demand and the return temperature. Moreover, excess heat can also be dissipated to the outside air via a re-cooler fitted on the roof, for example.
Можно наладить продажу горячей воды в теплосеть.
В Германии так можно продавать свое электричество от солнечных батарей например.
Греть воду для душа?
UFO just landed and posted this here
UFO just landed and posted this here
В глубинке часто бывают проблемы с интернетами.
Что такое горячее квадратное на кабель-росте?
Плитки фальшпотолка с горячего потока снятые.
Интересно, а как компания предполагает обслуживать оборудование, расположенное в этих шкафах? К клиенту будут постоянно приезжать работники фирмы и беспокоить его?

Что, если компания по каким-то причинам снизила мощность оборудования зимой? Клиент мерзнет?

Что насчет надежности электропитания? В ЦОДах все-таки резервирование, ИБП и так далее?

Что насчет надежности интернет-соединения? Вести в каждый дом такие же надежные каналы, какие ведут в ЦОДы?

Насколько потребуется увеличить штат сотрудников фирмы по обслуживанию оборудования и ее автопарк, учитывая, что специалистам придется теперь мотаться по всей округе значительную часть времени, вместо того, чтобы проводить работы по наладке оборудования?

Мне кажется, что лучше было бы сделать центральное отопление и горячее водоснабжение на базе ЦОДов. Температура конденсатора холодильной машины может оказаться недостаточной для обогрева воды и домов, но ее можно использовать хотя бы для предварительного подогрева воды перед тем, как жечь топливо для окончательного нагрева.
Проблемы питания и интернета можно решить многократным дублированием данных в разных локациях. Как в p2p.
Это также решает и проблему скорости.
Хм, да, вы правы. Но тогда придется фактически дублировать не только данные, но и оборудование, на котором они хранятся и обрабатываются. Экономическая целесообразность такого решения по сравнению с дублированием только питания и интернета — под вопросом, считать надо.

Ну и остальные проблемы по-прежнему актуальны: 1) надежность производства бесплатного тепла для клиента, если фирма не загружает оборудование целиком; 2) расширение штата и автопарка для обслуживания большого количества удаленных точек.
Оборудование дублировать не проблема, за него же платит пользователь.
Насчет обслуживания написал ниже.
А насчет обслуживания, средний сервер не требует обслуживания, кроме смены дисков.
Если в RAID добавить диски горячего резерва, то можно минимизировать выезд для обслуживания.

И если выводить на интерфейс для пользователя количество дисков горячей замены то он будет понимать состояние своей «печки» и что когда резерв исчерпается и RAID деградирует, то стойку удаленно отключат и тепло пропадет. Тогда он сам будет заинтересован вызвать специалиста для обслуживания до исчерпания резерва.
Еще в 2011 г. Microsoft Research озвучил, что есть смысл и коммерческая выгода в идее использования энергии, которая вырабатывается компьютерами, для отопления помещений и нагрева воды.

Пардоньте, но еще в СССР использовали тепло компьютеров для обогрева помещений. Мне рассказывали про какой-то НИИ с двумя рядом расположенными зданиями: в одном люди, в другом — компьютер. И обогрев первого за счет второго.
конторы решили прикинуться «благотворительным отоплением», вместо того, чтоб за аренду помещения платить )
а данные на дисках шифруются

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

Обеспечение же физической безопасности шкафов-рутинная задача, так что пока питание есть — шкафы в безопасности.

Если система построена с достаточным уровнем паранойи, любая попытка физического доступа должна останавливать работу машин (со снятием питания с ОЗУ), оставляя данные в полной сохранности.

Легкость DoS атаки в таком случае должна компенсироваться штрафами владельцам площадки.
пока питание есть — шкафы в безопасности

А когда питания нет — шкафы тем более в безопасности, т.к. никаких открытых данных на системной шине нет.

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

Значительную часть этой работы я могу сделать сам (как железо, так и софт), только заданные временные рамки не позволят все сделать самому. Наем 2-3 человек на полгода, допустим, съест 300 тысяч. Еще тысяч 100 — на покупку оборудования и изготовление прототипов. Мне останется до 100. Не так уж и много. Но проект интересный :)

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

Уточню еще раз задачу: разработать устройство, способное в реальном времени снимать, передавать и архивировать поток данных с модуля памяти, к примеру DDR3-1333 (это более десяти гигабит в секунду).

А, вы имели в виду рубли… Я имел в виду доллары. Тогда, возможно, ваши вопросы снимаются?

Задача мне понятна. С такими частотами и скоростями я работал. Также понимаю, что «сделать анализатор» и «подключиться им к схеме» — это две большие разницы, и если первую понятно как решать, то подключение мне видится более сложной задачей, учитывая, что все линии должны быть с контролируемым импедансом, ветвления не допускаются и т.д.
Вот что значит систему отсчета не так выбрать! Валюта по умолчанию :-) Все вопросы сняты, разумеется.
Пардон, если все перешифровано, то как сервер запустится после перебоя в питании? По любому должен быть какой-то загрузчик в открытом виде, который выполняет начальную загрузку и спрашивает по защищенному протоколу ключик для дешифровки данных на дисках на лету. Следовательно, возможен такой алгоритм:
  1. Отключаем питание
  2. Дампим и реверсим загрузчик
  3. Модифицируем загрузчик
  4. Запускаем
  5. Сохраняем полученный ключик
  6. Отключаем
  7. Profit!

Интересно, как можно обойти эту проблему, ведь тогда можно будет действительно сделать сервер с шифрованными дисками, в который не придется вводить ключи с клавиатуры при каждом перебое питания.
EFI прекрасно защитит от этого, так как нужно будет ей подсунуть загрузчик, защищенный правильной ЭЦП.

Кроме того, что-бы что-то там слить с жестких дисков, придется открыть шкаф, что (в идеале, в случае запредельной паранойи разработчиков) немедленно вызовет срабатывание охранной системы и полную блокировку серверов (можно и микросхемы FLASH памяти с ключами выжечь для вящей надежности).
А что будет проверять целостность EFI? :)
Еще можно написать клиент, который будет получать ключик от имени сервера.

Выходит, да, только аппаратная защита от вскрытия и поможет. А flash с ключиками будут менять при каждом техобслуживании (оставлять способ обхода «для своих» тоже не есть хрошо).
Если корпус сервера можно вскрыть в обход физической защиты — никакая программная защита не поможет, ключи найдут и украдут, если очень захотят.

То есть проблема защиты оборудования, находящегося на удаленной площадке — это в первую очередь задача обеспечения физической безопасности. Именно поэтому в датацентрах возводят решетки и разделяют зоны ответственности «туда не ходи — сюда ходи».
Отключаем питание

На плате может находиться микроконтроллер с батарейным питанием и ключами, сохраненными в статической памяти на кристалле. Срок службы такой батарейки для цели сохранения содержимого памяти может составлять годы. Как будете считывать эту память?

Дампим и реверсим загрузчик

Загрузчик зашифрован и подписан, код расшифровки и ключи находятся на микроконтроллере, защищенном от считывания. Ваши действия?
Трюк с заморозкой действует, если информация хранится в памяти, которую можно извлечь, вставить в программатор и считать. А если память находится на кристалле микроконтроллера, и ее содержимое недоступно снаружи? Лучшее, что тут можно сделать — это стачивание корпуса микросхемы и подключение напрямую к кристаллу микрощупами. Как бы в домашних условиях такое не делается.

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

www.youtube.com/watch?v=tCgtTPwlDSo
В целом получается, что из всех атак остается coldBoot — так как данные в ОЗУ будут хранится в расшифрованном виде, их можно попытаться оттуда выудить. Чтобы от этого уберечься, можно или поместить машину в сейф с гарантированной стойкостью 2*3=6 минут, или предусмотреть на модулях памяти специальный пин, снятие логической единицы с которого вызывало бы мгновенное обнуление всего банка. Тогда достаточно будет связать этот пин с системой сигнализации о вскрытии.
На какой шине? Данные логично шифровать на стороне клиента, до отправки в облако.
Как минимум после Сноудена.
В облаке данные не только хранятся, но и обрабатываются. Большинство методов обработки данных требуют их присутствия в облаке в расшифрованном виде.
Я думаю это решение именно для хранения, типа облачного CDN.
Делать такое решение для обработки будет не так эффективно:
— безопасность
— стоимость сервера на единицу объема будет выше, чем стоимость NAS, в 15 тысяч такой шкаф не уложиться
— географически распределенная сеть имеет больше смысла для хранения, чем для вычисления
А еще можно из этого сделать генератор электричества и питать сам сервер. Таким способом снизить расход за электричество
Генератор электричества? Из выделяемой тепловой энергии? Кпд прикинуть не пробовали, хотя бы если бы это была тепловая машина Карно?
Электростанция будущего будет состоять только из серверов, просчитывающих работу электростанции.
Sign up to leave a comment.