MinIO — прекрасное решение, когда надо легко и просто организовать объектное хранилище. Элементарная настройка, множество платформ и хорошая производительность сделали своё дело на ниве народной любви. Так что у нас не было другого пути, как месяц назад заявить о совместимости Veeam Backup & Replication и MinIO. Включая такую важную функцию, как Immutability. На самом деле у MinIO есть целый раздел в документации, посвящённый нашей интеграции.

Поэтому сегодня мы поговорим о том, как:

• Настроить MinIO очень быстро.
• Настроить MinIO чуть менее быстро, но значительно качественней.
• Использовать его в качестве Archive Tier для масштабируемого репозитория Veeam SOBR.

Вся прелесть и ужас VDDK ошибок в том, что, с одной стороны, совершенно точно понятно, где сломалось, а с другой — совершенно непонятно, почему, и как это теперь чинить. Это примерно как RPC call function failed в мире Windows.

Хотя не всё так ужасно, конечно же. Некоторые ошибки имеют совершенно конкретные причины и методы лечения. А некоторые — давно известный список наиболее частых причин и вариантов их исправления.

Наш Veeam Technical Support, конечно же, накапливает в себе подобные знания, и сегодня мы немного подглядим в их записи. Поэтому с превеликим удовольствием представляю вам топ самых частых VDDK errors и методы их устранения.

Когда мы сталкиваемся с неким программным продуктом, с которым нам предстоит взаимодействовать, сценарий взаимодействия мы вольны выбирать сами. Можно героически изобретать велосипед, а можно понадеяться, что авторы несколько лучше, чем мы, знают свой продукт, поэтому предоставляемый ими API (или набор библиотек) является оптимальным решением. На практике, к сожалению, не всё так радужно, но сегодня не об этом.

Для работы со своей дисковой подсистемой VMware уже много лет предоставляет VDDK — развесистый набор библиотек, документации и примеров кода, с помощью которых ваше приложение может работать с дисками виртуальных машин. Само собой мы в Veeam очень не любим изобретать ненужные велосипеды, поэтому VDDK в наших продуктах используется крайне активно.

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

Как все мы знаем, XFS — это высокопроизводительная журналируемая файловая система, созданная в недрах Silicon Graphics. А высокопроизводительная она потому, что способна справляться с множеством параллельных потоков ввода-вывода. Так что если вам интересна файловая система с легко масштабируемой пропускной способностью и не деградирующая от работы с несколькими устройствами одновременно, то вам, однозначно, сюда. Но сегодня мы будем нахваливать не весь XFS, а один конкретный его флаг — reflink. Он включает возможность переиспользовать одинаковые блоки данных между файлами, обеспечивая дедупликацию и возможность делать быстрые copy-on-write снапшоты.

Грешновато проходить мимо такой увлекательной функциональности, поэтому сегодня мы посмотрим, как reflink может помочь всем ответственным за бекапы, и что на этой ниве нам может предложить Veeam Backup & Replication 10.

Capacity Tier (или как мы называем его у себя внутри вима — каптир) появился ещё во времена Veeam Backup and Replication 9.5 Update 4 под именем Archive Tier. Заложенная в него идея — это дать возможность перемещать бекапы, которые выпали из так называемого operational restore window, на объектные хранилища. Это помогало расчищать дисковое пространство тем пользователям, у которых его было мало. А называлась сия опция Move Mode.

Для выполнения этого нехитрого (как кажется) действия достаточно было соблюсти два условия: все точки из перемещаемого бекапа должны быть за границами вышеназванного operational restore window, которое задаётся в явном виде в UI. И второе: цепочка должна быть в так называемом «запечатанном виде»(sealed backup chain или Inactive Backup Chain). То есть с течением времени в этой цепочке не происходит изменений.

Но в VBR v10 концепция дополнилась новыми функциями — появился Copy Mode, Sealed Mode и штука со сложновыговариваемым названием  Immutability.

Вот об этих увлекательных вещах мы сегодня и поговорим. Сначала о том, как это работало в VBR9.5u4, а потом об изменениях в десятой версии.



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

• Без малейших сожалений. Автор статьи.

Информация, загруженная в облако, уже никуда и никогда оттуда не пропадет! Именно так можно сформулировать одну из популярнейших IT легенд, восхваляющую незыблемость облаков и суляющую наступление всеобщего счастья от миграции с банальных on-premise серверов.
Однако на деле всё совершенно не так, и к угрозе потери данных в облаках надо относиться не менее серьёзно, чем к хранящимся на грешной земле. Вот об этом мы сегодня и поговорим: почему облака теряют данные, рассмотрим на примере Azure, какие варианты бекапов нам предлагают облачные вендоры, а на примере Veeam — как эти процессы можно улучшить.

Уже несколько месяцев прошло с момента релиза Veeam Backup & Replication 10. Даже была обзорная статья про грядущий релиз. А вот пост-релизной статьи посвящённой более детальному и техническому разбору самой ожидаемой функции новой версии — NAS Backup, так и не было.
Поэтому надо срочно исправляться.

Нет худа без добра! В очередной раз народная мудрость подтверждается, но только в этот раз с помощью осточертевшего коронавируса. Всех перевели на удалёнку, открыто много подписочного контента и, как следствие, в телекоме произошёл взрывной рост трафика. По разным оценкам, трафик в пользовательских сегментах уже вырос процентов на 80% и не думает останавливаться. Трафик попёр настолько сильно, что в нескольких странах Netflix, Youtube и прочие стриминговые сервисы сначала просили ограничить, а теперь им фактически запрещают передачу контента в HD качестве. Ибо пользователи настолько активно взялись за работу из дома, что места для развлечений в каналах у операторов просто не осталось.

А вот кто действительно сейчас не успевает подставлять мешки под поток хлынувших денег, так это провайдеры VPN-сервисов и всех, кто связан с их обслуживанием. Благо у одних своего VPN не было и проще купить готовый сервис, у других он был просто не рассчитан на такой поток пользователей и скончался под нагрузкой в первый же день. Словом, VPN — это сейчас самое популярное слово в телеком-мире. Вероятно, даже популярнее этой проклятой чумы.

И вот тут стоит задать себе вопрос — а в чём же сложность взять и организовать удобный VPN-сервис, а затем просто поддерживать его? Технология придумана далеко не вчера, все варианты давно известны, так почему же вокруг неё столько разговоров?

Но дабы не писать миллион первую статью про тонкости настройки OpenVPN, IPSec и прочих, давайте подойдём с другой стороны — а бывает так, что VPN делается быстро, удобно и бесплатно? Вот чтобы действительно десяток кликов — и работает как часы. И site-to-site, чтобы офисы связать, и site-to-point, чтобы удалёнщикам было быстро и удобно.

Спойлер — бывает.

Пруфы и рассуждения — под катом.

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

Вы сразу можете подумать: "Так это, наверное, какой-то ВУЗ особенный!" Возможно, но я не знаток вузовских рейтингов, поэтому расскажу только про то, что видел сам.

Итак, сегодня речь пойдёт про научные лаборатории в Московском Физико-Техническом Институте. Можно ли сделать что-то подобное в любом другом? Это вопрос к управляющим на местах. Может быть, уже и сделано, просто я был именно здесь и за всех остальных говорить не могу.

Изначально занесла меня нелёгкая в МФТИ с целью сделать нечто вроде обзорной экскурсии, но быстро выяснилось, что есть тема намного интересней: научная деятельность прямо в институтских стенах. Вот про неё мы и поговорим.

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

Внимание! Под катом развесистый лонгрид. Я предупредил.

Первый прототип объектных хранилищ мир увидел в 1996 году. Через 10 лет Amazon Web Services запустит Amazon S3, и мир начнёт планомерно сходить с ума от плоского адресного пространства. Благодаря работе с метаданными и своей возможности масштабироваться, не проседая под нагрузкой, объектные хранилища быстро стали стандартом для большинства сервисов по хранению данных в облаках, и не только. Другая важная особенность — это хорошая приспособленность для хранения архивов и подобных им редко используемых файлов. Все, кто был связан с хранением данных, ликовали и носили новую технологию на руках.

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

Поэтому сегодня мы разберёмся, какие есть варианты "Чтобы как у взрослых, а не CEPH и напильник побольше", развернём один из них, а проверять, что всё работает, будем с помощью Veeam Backup & Replication. В нём заявлена поддержка работы с S3-совместимыми хранилищами, и вот это заявление мы будем проверять.

Когда нет денег на железное хранилище от именитого вендора, или деньги есть, но негде взять железо для тестов, нам на помощь приходят Virtual Storage Appliance, или сокращённо — VSA. Виртуализированный контроллер столь желанного хранилища, позволяющий получить практически все функции своего железного собрата, кроме ну совсем уж экзотических и реализуемых только на физическом железе. VSA есть практически у всех (а может, и просто у всех) вендоров классических СХД: HPE, Dell EMC, NetApp, IBM и т.д. Бывают и обратные ситуации, вроде Nutanix и StarWind, но сегодня не о них. Для порядка не забудем открытые разработки во главе с FreeNAS, чей функционал вызывает уважение.

Другая особенность VSA, которой по определению лишены железные братья — наличие бесплатного функционала, обычно ограниченного допустимым размером хранилища и поддержкой “корпоративных” протоколов вроде FC. (Хотя нередко имеются и триальные версии на какой-то временной период, но речь сейчас не об этом.)

Сегодня мы рассмотрим работу с Dell EMC UnityVSA, начиная с первых шагов по развертыванию, включая создание файловой системы, настройки NAS и NDMP, а закончим интеграцией с Veeam Backup & Replication. Почему именно эта VSA? Просто потому что подобных материалов на Хабре я не нашёл и решил устранить эту несправедливость.

Вы не замечали (это утверждение), что все статьи про конференции и выставки делятся на два типа.

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

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

Но есть на выставках ещё и третий тип участников, без которых всё это выставочно-фестивальное счастье могло бы и не случиться вовсе. Это люди, работающие на стендах спонсоров, в простонародии — стендисты. И нет, девочки в миниюбках, раздающие сувенирку, к ним не относятся.

Вернувшись с трёх больших конференций (РИТ++ 2019, DotNext 2019 Piter и Heisenbug 2019 Piter), я решил написать эту статью, чтобы порассуждать о том, зачем спонсоры тратят на всё это деньги, сколько это стоит, что такое работа на стенде, почему сувенирки всегда не хватает на всех, и осветить прочие нюансы этого скрытого от большинства мира.
P.S. В качестве подзаголовков я решил использовать полярные отзывы посетителей о нашем стенде, которые нам присылают организаторы после конференций. С какой конкретно эти — не скажу.

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

Но, Петька, есть нюанс(с). Как и все наукоёмкие истории, лазерная техника уже достаточно успела обрасти слухами и мифами о своих безграничных возможностях. Возможностей там действительно вагон (или два), но физику никто не отменял.

Вооружившись острым желанием узнать, как это всё работает, было принято решение направиться за комментариями в питерский офис компании "Лазерный Центр". Они занимаются разработкой лазерных граверов и маркёров уже 15 лет и, вероятно, что-то в них понимают.

Много фотографий под катом.

На одной из встреч питерского сообщества .Net разработчиков SpbDotNet Community мы пошли на эксперимент и решили рассказать о том, как можно применять подходы, давно ставшие стандартом в мире Linux, для автоматизации Windows-инфраструктур. Но дабы не доводить всё до голословного размахивания флагом Ansible, было принято решение показать это на примере развёртывания ASP.Net приложения.

Быть спикером вызвался Алексей Чернов, Senior Developer команды, разрабатывающей библиотеки UI-компонентов для наших проектов. И да, вам не показалось: выступать перед .Net аудиторией пошёл JavaScript разработчик.

Кто заинтересовался итогом такого эксперимента, милости просим под кат за расшифровкой.

У нас в Veeam есть образовательный проект с лаконичным названием Veeam Academy. Посвящён он практике разработки на С#. Если не вдаваться в детали, то суть его такова: мы берём студентов-старшекурсников и за три месяца приводим их сугубо теоретические институтские знания в соответствие с окружающей действительностью. Делается это как с помощью лекций, где им раскрывают практический смысл той скучной теории, которую им успели дать в ВУЗе, так и с помощью общего проекта, разработкой которого они занимаются на протяжении всего обучения.

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

Но откуда студенты получают те самые практические навыки, спросите вы? Ответ кроется в наших разработчиках, которые на совершенно добровольных началах выступают в роли консультантов, делают code review для ребят и просто делятся своим опытом. Причём участвуют в этой деятельности исключительно senior девелоперы. Вот с ними-то (спустя уже 3 выпуска из академии) мы и решили побеседовать, чтобы узнать:

• Зачем они тратят своё ценное время на студентов?
• Каково это — быть ментором новичка?
• Как/зачем/почему жить с legacy-кодом?
• Чего не хватает современному образованию?
• Зачем люди идут в разработку коробочных продуктов?

Мы сделали небольшую серию видео-интервью Дудь-стайл, а тут будет небольшая текстовая выжимка из самых интересных ответов. Сейчас опубликованы два полных интервью (они есть в статье), но скоро будут выложены ещё три.

Начиная с шестой версии, в VMware vSphere есть удобная фича, позволяющая следить за актуальностью виртуальной инфраструктуры на удалённых площадках и филиалах, насаждая огнём и мечом стандарты виртуальной инфраструктуры главного офиса. Называется она Content Library и занимается распространением шаблонов между вашими дата центрами.

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

В Content Library можно ещё добавлять сопутствующие файлы, образы дисков и многое другое, но мы сегодня поговорим не про это. Несмотря на три года за плечами, всё ещё многие задаются вопросом “Как бекапить объекты внутри Content Library?”. Там лежат совершенно обычные файлы, с которыми точно так же может случиться любая беда, но доступа к ним через обычные варианты резервного копирования для виртуальных сред нет. Поэтому отвечаем под катом на столь важный вопрос...

"… Не может чуждой славянину
Быть чехов доблестных земля."
П.А. Вяземский

Небольшое предисловие

Нашего коллегу Андрея Дмитриева, как-то рассказавшего Хабру свою историю развития от бездомного до Senior Developer'a, недавно позвал поучаствовать в подкасте linkmeup наш другой коллега Loxmatiymamont. В рамках проекта "По'уехавшие" он общается с IT специалистами, которых объединяет одна деталь: когда-то они уехали работать из России в другую страну. Но, дабы не повторять миллион и тысячу подобных проектов, в этом подкасте нет разговоров про мотивацию, рассуждений "зачем и почему", а также поиска высших смыслов. Нет, здесь упор делается на бытовую часть вопроса жизни обычного человека в совершенно новом для него месте, без скучных сравнений а-ля "где огурцы дороже".

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

— Всем привет!
Нас [linkmeup] раньше любили обвинять в какой-то предвзятости и то, что наш проект периодически продается [выпуски с представителями вендоров — ред]. И вот сегодня у вас будет новый повод это сделать, потому что в гости я позвал своего коллегу – это Андрей Дмитриев, он сейчас работает в Праге. Привет, Андрей!

— Привет!

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

• Windows кластер с Windows Server 2012 r2 под капотом и неким количеством нод. Для удобства в моей лабе их всего две. Возникает законный вопрос: а зачем ставить кластер на кластер? Объясню чуть ниже.
• К кластеру по iSCSI зацеплено три диска: кворум, диск с базой (базами), диск для логов. Можно больше, можно меньше, тут кому как нравится. Иногда нравится так: два локальных диска (один для системы, второй для установки самого SQL), диск для кворума, совмещённый диск для root и system database, диск для базы, диск для логов, диск для TempDB и диск для Backups. Системщики говорят, что так тоже правильно. Но я считаю, что сколько у вас будет дисков — совершенно никакой роли не играет. Если именно у вас работает, значит вы правы и молодец.
• На каждой ноде установлен инстанс SQL, понимающий, что он часть SQL кластера, а Windows кластер видит роль SQL Server.

В ответ на своеобразный вызов коллег из Питера, устроивших у себя велоквест для С# разработчиков, мы, пражане, решили повторить мероприятие, и чтоб не хуже, а даже лучше. В итоге получилось совсем по-своему, но нам понравилось, и считаем, что затея в целом удалась. Попутно мы сделали несколько интересных для себя выводов. Так что этот заезд был всего лишь первым блином, дальше будет только лучше.

Диспозиция

С велосипедной точки зрения Санкт-Петербург и Прага – это два абсолютно разных мира. И нет, не из-за велодорожек. За ними вам надо в Нидерланды ехать, это там велосипедист царь и бог, который может страшно обматерить или даже специально задеть пешехода, зашедшего на велодорожку. Так что давайте немного разберём диспозицию:

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

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

В этот раз для меня героями выступили представители эстонского провайдера Infonet, которые, в честь ввода в эксплуатацию первой очереди своего дата-центра в Таллине Infonet DC, совместно с партнёрами из Комфортел организовали поездку для коллег из Санкт-Петербурга и Москвы. Причём сделали это необычайно приятно: вместо того, чтобы весь день хвалить себя любимых, они договорились о визитах в ещё два дата центра, оставив гостям возможность делать выводы и писать подобные отчёты. Кстати всего планировалось посетить 4 датика, но о грустных причинах посещения только трёх немного ниже.

Так что сегодня я хочу потратить немного вашего времени на рассказ про особенности рынка телекоммуникаций в Эстонии вообще и что такое дата-центры Таллина в частности.