— Да этот ЦОД можно развернуть и настроить, пока ты пиццу заказываешь!
Я бросил эти слова на совещании, и расплата пришла немедленно. Коллега предложила заказать пиццу. Оплачивает проигравший: если я успеваю собрать ЦОД — то она, если не успеваю — то я.
Чёрт!
В общем, встречайте стресс-тест: гиперконвергентное решение от Cisco с простой настройкой против приготовления пиццы.Читать полностью »
Вы просили показать реальные примеры использования наших корпоративных SSD-накопителей и профессиональные тесты. Предоставляем вашему вниманию подробный обзор наших SSD-накопителей Kingston DC500R и DC500M от нашего партнера Truesystems. Эксперты Truesystems собрали реальный сервер и эмулировали абсолютно реальные задачи, с которыми сталкиваются все твердотельные накопители корпоративного класса. Давайте почитаем, что у них получилось!
Это миф, достаточно распространённый в сфере серверного железа. На практике же гиперконвергентные решения (когда всё в одном) нужны много для чего. Исторически сложилось, что первые архитектуры были разработаны Amazon и Google под свои сервисы. Тогда идея была в том, чтобы сделать вычислительную ферму из одинаковых узлов, у каждого из которых есть собственные диски. Всё это объединялось неким системообразующим софтом (гипервизором) и разбивалось уже на виртуальные машины. Главная задача — минимум усилий на обслуживание одного узла и минимум проблем при масштабировании: просто докупили ещё тысячу-другую таких же серверов и подключили рядом. На практике это единичные случаи, и гораздо чаще речь про меньшее число узлов и немного другую архитектуру.
Но плюс остаётся тем же — невероятная простота масштабирования и управления. Минус — разные задачи по-разному потребляют ресурсы, и где-то локальных дисков будет много, где-то мало оперативки и так далее, то есть при разном типе задач будет падать утилизация ресурсов.
Получалось, что вы платите на 10–15% больше за удобство настройки. Это и вызвало миф из заголовка. Мы долго искали, где же будет применяться технология оптимально, и нашли. Дело в том, что у Циски не было своих СХД, но они хотели полный серверный рынок. И они сделали Cisco Hyperflex — решение с локальными хранилищами на нодах.
А из этого внезапно получилось очень хорошее решение для резервных дата-центров (Disaster Recovery). Почему и как — сейчас расскажу. И покажу тесты кластера. Читать полностью »
Работа сисадмина основана на вере, что инженеры ЦОДа знают свое дело. Мы создаем отказоустойчивые кластеры, но чего будет стоить эта отказоустойчивость, если отключится электричество? Какая разница, как быстро сервер обрабатывает запрос, если упал канал от ЦОДа до точки обмена трафиком? Как поднимать сервер, если он физически перегрелся?
А хотелось бы не верить, а знать, как именно создается отказоустойчивость на железном уровне. Откуда берутся те «девятки» надежности оборудования, о которых мы говорим, формулируя SLA Кубернетесов. Что происходит, когда проект горит в самом прямом смысле этого слова.
Нам повезло пройтись по ЦОД Selectel на третий день Слёрма DevOps, заглянуть в святая святых и даже кое-что сфотографировать на память. А также мы спросили о легендах компании, которые сотрудники Selectel никому никогда не рассказывают. Да и как выяснилось, сами уже не помнят.
Нашу компанию Southbridge связывают с Selectel давние партнёрские отношения. Сейчас мы поддерживаем 58 проектов, размещенных на серверах провайдера. Когда клиенту нужен сервер, расположенный в России, мы рекомендуем Selectel, потому что по опыту работы считаем его самым надежным и удобным провайдером IT-инфраструктуры.
Поехали!
Посвящаю этот пост тем людям, которые врали в сертификатах, из-за чего мы чуть было не установили у нас в залах бенгальские огни.
Истории больше четырёх лет, но публикую сейчас, потому что закончился NDA. Тогда мы поняли, что загрузили дата-центр (который сдаём в аренду) почти полностью, а энергоэффективность у него что-то не очень улучшилась. Раньше гипотеза была в том, что чем сильнее мы его заполняем, тем лучше, потому что инженерка распределяется на всех. Но оказалось, что мы себя в этом плане обманывали, и при хорошей загрузке где-то были потери. Работали мы по многим направлениям, но наша отважная команда занялась охлаждением.
Реальная жизнь дата-центра — это немного не то, что в проекте. Постоянные докручивания от службы эксплуатации для повышения эффективности и оптимизация настроек под новые задачи. Вот взять мифическую среднюю стойку. На практике её не бывает, по нагрузке распределение неравномерное, где-то густо, где-то пусто. Вот и пришлось кое-что перенастроить для лучшей энергоэффективности.
Наш дата-центр Компрессор нужен для самых разных заказчиков. Поэтому там посреди обычных двух–четырёхкиловаттных стоек может оказаться вполне себе 23-киловаттная или больше. Соответственно кондиционеры были настроены на то, чтобы охлаждать их, и через менее мощные стойки воздух просто проносился мимо.
Вторая гипотеза была в том, что тёплый и холодный коридоры не смешиваются. После замеров могу сказать, что это иллюзия, и настоящая аэродинамика отличается от модели примерно всем. Читать полностью »
Объект на «плавающем» фундаменте для защиты от землетрясений.
Меня зовут Павел, я руковожу в КРОК сетью коммерческих дата-центров. Мы за последние лет 15 построили заказчикам точно больше сотни ЦОДов и крупных серверных, но этот объект — самый крупный из зарубежных. Он находится в Турции. Туда я и поехал на несколько месяцев, чтобы консультировать иностранных коллег при строительстве самого объекта и облака.
Здесь много подрядчиков. Естественно, мы часто общались с местной ИТ-интеллигенцией, поэтому у меня есть что рассказать про рынок и про то, как там всё в ИТ выглядит для русского человека со стороны. Читать полностью »
На прошлой неделе стартовали продажи нового серверного процессора AMD EPYC 7002 на базе микроархитектуры Zen 2. О планах использовать его в своих WJL уже объявили Google и Twitter.
Мы много говорим о возможностях экономии энергии в ЦОД за счет продуманного размещения оборудования, оптимального кондиционирования и централизованного управления электропитанием. Сегодня речь пойдет о том, каким образом можно экономить энергию в офисе.
Самая главная транспортная проблема в Питере — это мосты. Ночью из-за них приходится убегать из кабака, не допив пиво. Ну или платить за такси в два раза больше обычного. Утром — тщательно рассчитывать время, чтобы как только мост свели, ты ловким мангустом успел на вокзал. Вариант "ночевать где-нибудь в центре, рядом с вокзалом" мы не рассматриваем, как идеологически вредный.
..."Сапсан", уходящий в 5:30, придумали люди, которые ненавидят сов. Нет, разумеется, очень удобно оказаться в Москве в девять утра, а Питер безумно прекрасен во время белых ночей, но в половину пятого, когда я сел в такси, мне хотелось повернуть голову на 270 градусов тому жаворонку, который придумал этот утренний поезд.
"Все хорошие датацентры похожи друг на друга" — думал я, когда узнал, что нас пригласили в гости ребята из DataLine.
Как оказалось, каждый датацентр хорош (или плох) чуточку по-своему, особенно когда набьёшь шишек, соберёшь все грабли в округе и выучишь уроки из собственного (и, немножечко, чужого) богатого опыта. Вот мы (в составе пяти ведущих linkmeup и примкнувших к ним друзей и сочувствующих) и решили проверить, насколько хороши (или не очень) датацентры OST и NORD.
Наши турецкие клиенты попросили нас правильно настроить бэкап для дата-центра. Мы делаем подобные проекты в России, но именно здесь история была больше про исследование того, как лучше сделать.
Дано: есть локальное S3-хранилище, есть Veritas NetBackup, который обзавёлся новым расширенным функционалом по перемещению данных в объектные хранилища теперь уже с поддержкой дедупликации, и есть проблема со свободным местом в этом локальном хранилище.
Задача: сделать всё так, чтобы процесс хранения резервных копий был быстр и дешев.
Собственно, до этого в S3 всё складывалось просто файлами, причём это были полные слепки критичных машин дата-центра. То есть не так, чтобы очень оптимизированно, но зато всё работало на старте. Сейчас же пришло время разобраться и сделать правильно.
На картинке то, к чему мы пришли:
Как видно, первый бэкап делался медленно (70 Мб/с), а последующие бэкапы тех же систем — значительно быстрее.
Собственно, дальше чуть больше деталей про то, какие там особенности. Читать полностью »
