• Резервное копирование на кассеты

      Есть сеть примерно из 90 очень крупных магазинов по России. Каждый магазин бэкапится на ленточную библиотеку (ниже на фото — ЗИП). Дальше они берут кассеты и везут их на машине в архив.



      Устройства механические: они ломаются, выходят из строя, мы ездим чинить. Потом они сходят с расширенной гарантии, и это всех бесит.

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

      Мы было подумали про центральную инсталляцию одной большой железки, но ситуация осложнялась тем, что каналы от магазинов ограничены 5 Мбит/с (от самых дальних).
      Читать дальше →
    • Как отрубали свет в маленьком дата-центре: дешёвый способ аварийного развёртывания



        Есть небольшой дата-центр около производственной компании в небольшом городе довольно далеко от Москвы. Он нужен круглосуточно. Так получилось, что ввод от электросети там только один, а ДГУ нет. Потому что компания не айтишная, а производственная, правильно проектировать они когда-то не стали. Потому что когда-то всё и так работало.

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

        Админ предложил купить дизель, но бизнес сказал, что это не админское дело. Его дело — обеспечить простой не больше часа. В оборудование они только что вбухали много денег, поэтому уходить в облако нельзя, а коммерческих дата-центров, чтобы перевезти туда оборудование, поблизости нет.
        Читать дальше →
        • +29
        • 12,1k
        • 4
      • А вот вы говорите Ceph… а так ли он хорош?


          Я люблю Ceph. Я работаю с ним уже 4 года (0.80.x — 12.2.6, 12.2.5). Порой я так увлечен им, что провожу вечера и ночи в его компании, а не со своей девушкой.
 Я сталкивался с различными проблемами в этом продукте, а с некоторыми продолжаю жить и по сей день. Порой я радовался легким решениям, а иногда мечтал о встрече с разработчиками, чтобы выразить свое негодование. Но Ceph по-прежнему используется в нашем проекте и не исключено, что будет использоваться в новых задачах, по крайней мере мной. В этом рассказе я поделюсь нашим опытом эксплуатации Ceph, в некотором роде выскажусь на тему того, что мне не нравится в этом решении и может быть помогу тем, кто только присматривается к нему. К написанию этой статьи меня подтолкнули события, которые начались примерно год назад, когда в наш проект завезли Dell EMC ScaleIO, ныне известный как Dell EMC VxFlex OS.


          Это ни в коем случае не реклама Dell EMC или их продукта! Лично я не очень хорошо отношусь к большим корпорациям, и черным ящикам вроде VxFlex OS. Но как известно, всë в мире относительно и на примере VxFlex OS очень удобно показать каков Ceph с точки зрения эксплуатации, и я попробую это сделать.

          Читать дальше →
        • 9 лет инкапсулированного развития — как работает проектная команда в корпорации из 2500 человек



            У нас тут масса историй, начиная с того, как мы переманили MS-разработчика в Питон, и заканчивая тем, как разработка поставила тикет найти бутсы для президента Федерации футбола Уганды. Но я бы хотел рассказать не только их, а, скорее, то, на что похожа работа внутри большой компании.

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

            У нас свои кабинеты на этаже инженеров, свои выделенные маркетологи, свои команды разработки и поддержки, частично своя бухгалтерия. Мы пользуемся всеми благами компании (можем даже иногда поманить печеньками к себе в направление инженеров из других отделов), но при этом работаем почти отдельно.

            Хочу рассказать, на что это похоже. Потому что, с одной стороны, у нас есть доступ к ресурсам, которых никогда не будет у отдельной компании, а с другой — есть и ограничения.
            Читать дальше →
          • Glusterfs + erasure coding: когда надо много, дешево и надежно

              Гластер в России мало у кого есть, и любой опыт интересен. У нас он большой и промышленный и, судя по дискуссии в прошлом посте, востребованный. Я рассказывал о самом начале опыта переноса бекапов с Enterprise хранилища на Glusterfs.

              Это недостаточно хардкорно. Мы не остановились и решили собрать что-то более серьёзное. Поэтому здесь речь пойдёт о таких вещах, как erasure coding, шардинг, ребалансировка и её троттлинг, нагрузочное тестирование и так далее.



              • Больше теории волюмы/сабволюмы
              • hot spare
              • heal / heal full / rebalance
              • Выводы после ребута 3 нод (никогда так не делайте)
              • Как влияет на нагрузку сабволюма запись с разной скоростью от разных ВМ и shard on/off
              • rebalance после вылета диска
              • fast rebalance

              Читать дальше →
            • Байки облака



                Сразу предупрежу: это не те байки, где крысу разорвало в хлам. Просто разные мелкие истории «как люди делают», которые могут быть полезны администраторам. А могут и не быть. У нас много довольно крупных заказчиков, и у них, соответственно, компетентные админы. По опыту скажу: часто опытнее там, где есть строгие ограничения по бюджету.

                У нас есть заказчик, который перепродаёт наше облако (как оказалось), есть управление выпеканием хлеба из облака, есть даже развёрнутый CTF для обучения хакеров. Но давайте начнём с переездов, в том числе тех, которые возникли из-за перекопанных экскаваторами дорог Москвы.
                Читать дальше →
              • Как нашего заказчика не хотел отпускать провайдер



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

                  Представьте: вы CIO. Бюджета на аварийную дублирующую площадку у вас нет. Старого оборудования тоже нет. Бизнес связан с предоставлением медицинских услуг, здесь каждый лишний час промедления стоит дорого: один день простоя грозит финансовыми и имиджевыми потерями, равными годовой прибыли, два часа — начнут страдать клиенты.

                  А теперь добивающий аккорд: переезд вам по факту осложняют, ставя в рамки и согласовывая каждый чих по месяцу. Потому что вы же много платите провайдеру, зачем вас отпускать?
                  Читать дальше →
                • Наш многолетний эксперимент – внедрение Dell EMC ScaleIO в Облаке КРОК



                    Над большой тестовой инсталляцией, на которой крутился сторадж на базе ScaleIO от Dell EMC, мы издевались всяческим образом пару лет точно, а то и больше. Внесли огромное количество исправлений и допилили наконец-то продукт под нашу облачную инфраструктуру. Сторадж заполняет у нас крайне востребованную нишу между обычным медленным хранилищем на базе HDD и скоростным решением на all-flash массивах. Более того, в силу своей Software Defined специфики он позволяет собирать отказоустойчивые стораджи чуть ли не из палок с ветками. Только учтите, что совсем экономить на железе смысла нет, стоимость лицензии перевесит выгоды от экономии.

                    Короче говоря, сегодня я расскажу вам, как мы внедряли ScaleIO и ходили по граблям с закрытыми глазами. Про архитектурные особенности стораджа и его интеграцию в Облако. И, конечно, будет про нагрузочное тестирование. За подробностями — добро пожаловать под кат.
                    Читать дальше →
                    • +31
                    • 6,1k
                    • 7
                  • Как мы ломали Glusterfs



                      История началась год назад, когда к нам пришёл наш друг, коллега и большой эксперт по энтерпрайз стораджам со словами: «Парни, у меня тут завалялась шикарная хранилка со всеми модными фичами. 90Tb». Особой необходимости мы в ней не видели, но, естественно, отказываться не стали. Настроили туда пару бекапов и на какое-то время благополучно забыли.

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

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

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

                      Из множества вариантов наш взгляд особенно зацепил Глустер, Гластер. Всё равно, как называть. Лишь бы результат был. Поэтому мы начали над ним измываться.
                      Читать дальше →
                    • Упали с AWS? Заезжайте без вопросов, документы потом, сейчас не до того

                        Пока я ехал на работу и слушал новый альбом Дельфина, кто-то блокировал IP адреса Amazon и Google целыми подсетями. Роскомнадзор назвал недостоверной информацию о блокировании сайтов, не имеющих отношения к Telegram, но арендующих IP-адреса на тех же, что и мессенджер, сервисах, и создал горячую линию для противодействия распространения таких сообщений.

                        Поэтому я даже не догадываюсь, почему нам пришлось в течение вчерашнего дня помогать нескольким сервисам. Кого-то задело совсем немного, а кому-то пришлось мигрировать.

                        Если очень коротко — мы умеем быстро мигрировать из AWS. У нас совместимый API. Мигрировать клиентов из Google тоже можем. И в ближайшие недели мы готовы делать миграцию бесплатно и давать месяц на тесты в нашем облаке без договора и без гарантийного письма, просто по карточке компании. Не понравится — ничего платить не надо.

                        Ниже — howto для разных типов выгрузки ВМ с Амазона.
                        Читать дальше →
                      • Как в 2009 году мы начали строить облако, и где ошиблись



                          В октябре 2009-го мы всё перепроверили. Надо было строить дата-центр на 800 стоек. На основании нашей интуиции, прогнозов по рынку и американской ситуации. Вроде как звучало логично, но было страшновато.

                          Тогда «облачных» вычислений в России не было, как и облачных хостингов. Собственно, и само слово-то почти не использовалось на рынке. Но мы уже видели по Америке, что там подобные инсталляции пользуются спросом. У нас были за плечами большие проекты создания HPC-кластеров для авиаконструкторов на 500 узлов, и мы верили, что облако — это такой же большой вычислительный кластер.

                          Наша ошибка была в том, что в 2009 году никто не думал, что облака будут использоваться для чего-то, кроме распределенных вычислений. Всем нужно процессорное время, думали мы. И начали строить архитектуру так, как строили HPC-кластеры для НИИ.

                          Знаете, чем принципиально такой кластер отличается от современных облачных инфраструктур? Тем, что у него очень мало обращений к дискам и всё чтение более-менее последовательное. Задача ставится одна, разбивается на куски, и каждая машина делает свой кусок. На тот момент никто не брал серьезно в расчет, что профиль нагрузки на дисковую подсистему для HPC-кластеров и облака принципиально разный: в первом случае это последовательные операции чтения\записи, во втором — полный рандом. И это была не единственная проблема, с которой нам пришлось столкнуться.
                          Читать дальше →

                        Самое читаемое