В нашем случае email и sms уходят уже ответственным лицам.
С учетом того, что за мониторами круглосуточно сидит как минимум один инженер, ему слать sms не нужно.
Еще в центре мониторинга срабатывает звуковое оповещение (противное такое:)), так что дежурному будет сложно пропустить аларм.
Если у вас никто не сидит постоянно за экранами мониторинга, то можно другие варианты оповещения использовать.
RTO=1 час обеспечивается средствами резервного сервера для SAP HANA. В случае аварии на основном сервере данные доступны на резервном.
В случае обычного запроса на полное восстановление из бэкапа у нас есть 4 часа.
База 256 GB.
А ваше облако каким-то образом сертифицировано SAP-ом под HANA (спрашиваю потому что обнаружить вас в списке SAP HANA Certified IaaS Platforms не удалось)?
У клиента развернут частный кластер на базе оборудования, входящем в лист сертификации SAP для размещения HANA (TDI).
27 MB/s? Что- то совсем не быстро. Дедупликация где выполнялась? На HANA-хосте или медиа-агенте?
Это время включает в себя дедупликацию, сжатие и собственно передачу данных. Для shared системы резервного копирования — это приемлемая скорость. На выделенных решениях, например, кейс 2, скорость будет выше – до 3 Gb/s. Дедупликация на стороне клиента.
Хм… на LTO-6 картридже с компрессией вполне себе лежат 4 бекапа 1.5TB базы.
Да, возможно, в вашем случае этот вариант приемлем. В нашем же кейсе клиент использовал ленты LTO-5 в качестве основной системы хранения. Наличие сжатия никак не отменяло большое количество картриджей. Более того, степень сжатия не гарантируется и варьируется от случая к случаю, поэтому и остановились на СХД.
клиент хостит HANA'у на выделенных физ. машинах или на виртуалках?
Уже сейчас мы можем подключать к DataLine-IX через наши точки присутствия на ММТС-9 с помощью IP/MPLS сети. Когда наберём критическую массу, разместим там железо DataLine-IX.
Да, каждый пир имеет по 2 сессии. Сейчас BGP «крутится» на BIRD, но предполагается миграция одного из серверов на иную платформу.
К варианту с Quagga мы подходим острожно, т. к. в сообществе пользователей есть мнения о плохой масштабируемости, касающейся возможностей поддержки большого количества BGP сессий.
Третью часть не обещаю, но подумаю).
Сервера полностью независимы друг от друга. Участник устанавливает сессии с каждым из RS. При падении/обслуживании одного сервера второй остается полностью работоспособным и обслуживает клиентов.
У нас развернуто два сервера маршрутизации. Да, можно сказать, что с RS — это route-engine, обособленный от коммутаторов. Каждый участник устанавливает BGP сессию с RS, далее на сервере после применения всех фильтров в master таблице маршрутизации формируется итоговый набор маршрутов для анонса остальным участникам. При анонсе маршрута участника атрибут next hop остается неизменным. За счет этого трафик идет напрямую через L2 домен коммутационной фабрики IX, которая построена на базе «черных бриллиантов».
Если представить IX как один виртуальный коммутатор, то RS — это control-plane, а «черные бриллианты» — data-plane точки обмена трафиком.
Состояние маркировок у нас проверяется во время ежедневных обходов дежурными инженерами и в рамках ТО инженерного оборудования. Так что, если что-то отвалилось или стало нечитаемым, то маркировку заменят сразу.
Да, очень хорошее замечание. Важно выбирать правильные материалы для маркировки, учитывая, где расположено оборудование: на улице или помещении, подвержено ли оно нагреву или наоборот холодным температурам. Мы в зависимости от этих условий используем разные типы маркировочных лент.
Физика в дата-центре та же самая: теплый воздух поднимается вверх, холодный остается внизу. Сверху собирается подушка горячего воздуха, который разбирается шкафными кондиционерами. Внизу в холодном коридоре образуется слой холодного воздуха, забираемого серверами на охлаждение. Холодный внизу, теплый вверху, они не смешиваются, всем хорошо. Если холодного воздуха из-под фальшпола поступает достаточно, то его хватает на всю высоту стойки. Если серверы берут больше, чем подается из-под фальшпола, подушка горячего воздуха над холодным коридором опускается вниз, верхние юниты начинают брать теплый воздух и могут перегреться (это если нет изоляции холодных коридоров). Такая схема лаконична и проверена десятилетиями.
Действительно, можно заливать холодный воздух в холодные коридоры сверху, но делать это нужно через воздуховоды, которые стоят денег, занимают очень много места. Если понадобится поменять расстановку стоек, они потребуют переконфигурации и т.д. Иногда так действительно делают, но не от хорошей жизни, а, например, когда в помещении почему-либо невозможно поставить фальшпол.
На хладокомбинате холод подают сверху, потому что холодный воздух сам опускается вниз и равномерно остужает то, что сложено в камере. Если подавать снизу и не перемешивать, внизу будет холодно, а наверху останется слой теплого воздуха.
Нельзя сказать, что фальшпол — это обязательно и без него никак. Есть системы с альтернативными способами подачи воздуха, но в наших дата-центрах практически везде мы используем фальшпол. В этом случае недостаточно просто сделать фальшпол, поставить перфорированные плитки и «загнать» под него воздух. Необходимо правильно рассчитать объем подфальшпольного пространства и объем подаваемого воздуха, чтобы обеспечить необходимый уровень избыточного давления холодного воздуха.
Спасибо. Рады, что вам интересно.
Давайте дадим коллегам шанс исправиться :)
Напишите в личку. Прослежу, чтобы ваше резюме дошло до адресата. И если у нас есть подходящие вакансии, ответ обязательно будет.
Изоляция холодных или горячих коридоров (построение крышии боковых дверей) можно сделать заранее, когда известно, что в рядах будут располагаться стойки одного типа. Когда стойки разные, как в нашем случае, сделать такую изоляцию удобнее уже после установки стоек. Чтобы не было паразитного воздухообмена (холодный воздух не смешивался с горячим), мы устанавливаем в свободные юниты специальные заглушки (на фото салатовые вставки). Вообще полная изоляция холодных и горячих коридоров в нашем случае вещь опциональная.
Решение c беспроводным IP KVM у нас возникло не просто так. Мы посмотрели статистику по запросам, и, как оказалось, запросов на KVM значительно больше, чем запросов на IPMI, хотя IPMI мы также предоставляем.
С учетом того, что за мониторами круглосуточно сидит как минимум один инженер, ему слать sms не нужно.
Еще в центре мониторинга срабатывает звуковое оповещение (противное такое:)), так что дежурному будет сложно пропустить аларм.
Если у вас никто не сидит постоянно за экранами мониторинга, то можно другие варианты оповещения использовать.
В случае обычного запроса на полное восстановление из бэкапа у нас есть 4 часа.
База 256 GB.
У клиента развернут частный кластер на базе оборудования, входящем в лист сертификации SAP для размещения HANA (TDI).
Это время включает в себя дедупликацию, сжатие и собственно передачу данных. Для shared системы резервного копирования — это приемлемая скорость. На выделенных решениях, например, кейс 2, скорость будет выше – до 3 Gb/s. Дедупликация на стороне клиента.
Да, возможно, в вашем случае этот вариант приемлем. В нашем же кейсе клиент использовал ленты LTO-5 в качестве основной системы хранения. Наличие сжатия никак не отменяло большое количество картриджей. Более того, степень сжатия не гарантируется и варьируется от случая к случаю, поэтому и остановились на СХД.
HANA работает на виртуальных машинах.
Под миграцией подразумевается и иная ОС, и иной routing daemon. Подробностей пока сказать не могу, т. к. активная фаза тестирования еще впереди.
Рады, что статьи оказались интересными для вас :). Постараемся еще что-нибудь написать на эту тему в новом году.
К варианту с Quagga мы подходим острожно, т. к. в сообществе пользователей есть мнения о плохой масштабируемости, касающейся возможностей поддержки большого количества BGP сессий.
Третью часть не обещаю, но подумаю).
Если представить IX как один виртуальный коммутатор, то RS — это control-plane, а «черные бриллианты» — data-plane точки обмена трафиком.
Технически это запретить нельзя. Держится на понимании участником принципов маршрутизации. Как говорится, запрещено не технически, а уставом :)
С помощью BGP фильтров на основе IRR.
Действительно, можно заливать холодный воздух в холодные коридоры сверху, но делать это нужно через воздуховоды, которые стоят денег, занимают очень много места. Если понадобится поменять расстановку стоек, они потребуют переконфигурации и т.д. Иногда так действительно делают, но не от хорошей жизни, а, например, когда в помещении почему-либо невозможно поставить фальшпол.
На хладокомбинате холод подают сверху, потому что холодный воздух сам опускается вниз и равномерно остужает то, что сложено в камере. Если подавать снизу и не перемешивать, внизу будет холодно, а наверху останется слой теплого воздуха.
Давайте дадим коллегам шанс исправиться :)
Напишите в личку. Прослежу, чтобы ваше резюме дошло до адресата. И если у нас есть подходящие вакансии, ответ обязательно будет.