• Как мы организовали хранилище данных дешевле Amazon Simple Storage Service на 35%



      У нас есть набор систем хранения как традиционных, так и программно определяемых. Они используются в формате блочных хранилищ для хранения виртуальных машин, баз данных и других ресурсов.

      На втором этапе мы стали использовать объектное хранение, то есть хранение без иерархии каталогов. Все данные лежат на одном уровне, и каждый файл может быть доступен по своему ключу. Метаданные хранятся рядом с файлом. Для доступа используются простые команды уровня PUT — GET — MODIFY, есть возможность обратиться к каждому файлу по собственному URI, обеспечены лёгкость управления правами и лёгкость размещения самых разных данных и доступа к ним.

      Минус данных решений — невозможность обращения к части (сегменту) файла, поэтому для приложений вроде баз данных такие хранилища не используются. Оптимальное применение — сложить туда картинки веб-сайта, файловую помойку, архивы или бэкап данных. На базе объектного хранилища мы построили свой S3 — систему хранения не очень часто изменяемых данных. С прямой совместимостью с Amazon S3.

      А ещё классические протоколы доступа, использующиеся внутри компаний для файлового доступа (CIFS или NFS), не предназначены для обмена большими данными через сеть Интернет. Это ещё одна из причин, почему и зачем мы создали своё объектное хранилище.

      Стояла задача сделать его не просто работающим отовсюду, но и дешёвым.
      Читать дальше →
    • Кому НЕ надо переезжать в облако и почему



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

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

        Более сложная ситуация — это когда железо кто-то купил 20 лет назад (я сейчас не шучу), а оно ещё нужно. Точнее, нужно что-то, совместимое с ним. Я видел софт, который писался 15 лет назад, 20 лет назад и даже 25 лет назад. Тот, кто его писал, давно уже умер или не работает. А это, например, реестр в госструктуре на мейнфрейме или код банка, привязанный к микроинструкциям конкретной линейки процессоров или специфическим функциям ОС. Исходников нет. Документация только для эксплуатации. Если повезёт.

        Так вот, если кто-то говорит, что это можно взять, отреверсить и переписать на современном языке, — плюньте ему в лицо, наступите на спину и попрыгайте.
        Читать дальше →
      • Срочный переезд с Amazon Web Services — истории двух клиентов



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

        19 апреля они заметили блокировку одного из IP-адресов своего публичного сервиса частью провайдеров на территории РФ. 20 апреля ситуация усугубилась — вся подсеть стала недоступной. Это уронило тестовую среду, один из резервных каналов, частично нарушило работу почтовых серверов. Проблему удалось решить заменой IP-адресов, проксированием трафика через другие дата-центры.

        Когда стало понятно, что всё это всерьёз и надолго (точнее, когда возник такой риск), один наш заказчик, компания Теко — международная процессинговая компания, решил развернуть инстанс в нашем облаке. Их CIO была важна большая федеративность сервиса, большее присутствие на территории РФ. Цитата:

        «Облако в РФ даёт больше гарантий клиентам, что сервис не будет заблокирован РКН. Скорость, с которой нам предоставили ресурсы, была очень важна. Происходило всё достаточно быстро: первым делом мы добавили GEO dns для доступности сервиса на территории РФ, начали проксирование трафика через незаблокированные ДЦ. Медленная часть — федерация для БД».
        Читать дальше →
      • Управляем большим длинным проектом: почему важно разговаривать словами



          У меня в подчинении был один руководитель проектов, который никогда не собирал совещания. Он был немного хикки и обладал исключительным перфекционизмом (насколько это возможно для ПМа), что выражалось в стремлении всё происходящее фиксировать в почте. Письма были очень детальные, на несколько страниц: содержали все нужные описания, в них фиксировались все обещания, сроки, хотелки, большое внимание уделялось договорённостям и упрёкам в безответственности исполнителей. В общем, идеальные письма, последовательно излагающие ход событий, — хоть книгу по ним пиши.

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

          Я регулярно просил его собирать руководителей команд, работающих над проектом (инженеров по железу, разработчиков и так далее). Исходя из моего опыта, проблема, скорее всего, была в том, что команды не менялись информацией между собой.

          Он собрал совещание, но на нём молчал. И все молчали. Точнее, докладывали статусы и поднимали проблемы. Результат совещания — он написал ещё одно длинное письмо с требованиями и фиксацией статусов с косяками.

          Задержки продолжили копиться.
          Читать дальше →
        • Как мы побеждали бардак с железом и становились бюрократами с нуля


            Разница между документацией и базой знаний: документация говорит, что это устройство охлаждает воздух до +18 градусов по Цельсию, а база знаний подсказывает, что есть редкий баг, когда два датчика сразу показывают -51 тысячу градусов и устройство начинает лихорадочно греть воздух для серверов.

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

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

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

            В общем, первые же грабли вас или убьют к чертям, или научат делать всё правильно. У нас случилось второе и без граблей. Почти без граблей. Если у вас уже есть хаос, то наш опыт может оказаться полезным, потому что сейчас нам стало лучше.
            Читать дальше →
          • Дата-центр с интересной физической защитой



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

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

              Сначала нас остановит забор с набором датчиков. Если его потрясти в любом месте или попробовать на него залезть, то сработает датчик вибрации, и сразу выдвинется патруль охраны.
              Читать дальше →
            • Откуда возьмутся цифровые инженеры


                Источник


                "Талант сам по себе бесцветен и приобретает окраску только в применении".
                М.Е. Салтыков-Щедрин


                Кадры действительно решают всё. А в условиях развития цифровой экономики кадры нужны особенные. И для взращивания таких кадров надо создать соответствующие условия.


                Несмотря на все проблемы ИТ-отрасль остается одной из самых эффективных в экономике России. Согласно оценке Минкомсвязи, один сотрудник в данной сфере создает продукцию и услуги на сумму в среднем более 2 млн. рублей в год. Но только 15-20% выпускников готовы к немедленному трудоустройству и эффективной работе в сфере ИТ, по оценкам экспертов Института развития Интернета (ИРИ) «Взаимодействие ИТ бизнеса и ВУЗов». Что же пошло не так в вузовском образовании?

                Читать дальше →
              • Считаем серверы, рабочие станции, лицензии, разливаем обновления и автоматизируем IT-процессы

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

                  Случай всплыл в памяти по ходу написания статьи. Уже давно собирался рассказать о специальной софтине для сбора всяких инвентаризационных штук с железок — KACE. С ней я знаком как минимум пару лет и не раз приходилось поработать на практике. Сейчас сошлись звезды, мысли собрались в кучу и, наконец, пишу как эта штука может быть полезна для контор от нескольких рабочих станций до многотысячных парков ИТ-оборудования. Вещь простая как валенок и функциональная как микроволновка с грилем и конвекцией, а развернутой статьи на Хабре про нее до сих пор не было.

                  image
                  Посчитать всё
                • Я сетевой архитектор, и меня это беспокоит


                    100G с разбивкой на 4х25 в нашем дата-центре

                    Основа работы сетевого архитектора на *aaS-проектах — это как строить здание, которое эволюционирует. Вроде была пятиэтажка, когда построили четыре этажа, стало надо делать ещё 21, потом понадобилось пристроить домики, соединённые туннелями под землёй, а потом всё это должно стать огромным жилым комплексом с крытым двориком. И ещё там внутри жильцы, и им нельзя перекрывать канализацию, водопровод и подъезды.

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


                      Источник


                      По моим оценкам, в мире может существовать сотня-другая систем мониторинга (если у вас есть более точное аргументированное число — приглашаю в комментарии). Это и облачные системы, on-premise, коммерческие, бесплатные, для сети, инфраструктуры и так далее и по всем фронтам. Среди них есть те, что поддерживают создание сервисно-ресурсных моделей. Это такие древовидные штуки, к узлам которых привязаны элементы бизнес-системы: веб-серверы, базы данных, серверы приложений, коммутаторы и много других страшных слов. Каждый дочерний элемент влияет на родительский. Например, если на каком-то сервере превышен порог использования оперативной памяти, создается событие (допустим, критичности Critical — красное), которое влияет на объекты выше по структуре сервиса.


                      Многие организации привязывают доступность бизнес-системы к доступности бизнес-процесса. Если бы я считал SLA, получилось бы, что доступность ИТ-системы упала до нуля (в момент превышения порога по памяти на каком-то там сервере), а бизнес-процесс остановился. Но это же не так!? Внизу дерева может быть кластер или, вообще, забивание памяти под завязку — нормальный режим работы системы. Короче, задача звучит так: как правильно рассчитывать доступность бизнес-процесса и не оглядываться на некритичные события от компонентов бизнес-систем? Её и разберем.

                      Следить и не отвлекаться
                    Самое читаемое