Утро админа: добавляем место на десятках серверов за кофе

    Каждый день мне приходится добавлять место на одном, двух, трех, пяти, а бывает – и десяти database серверах. Почему? Потому что для них характерен естественный рост баз. Серверов сотни, все они виртуалки с дисками на thin provisioning. Если им заранее выдать много места, то будет обязательно какой нибудь “runaway”, типа апгрейда с переливом таблиц, который пожрет все это место, а если не пожрет, то поднадкусает. Как вы знаете, thin provisioning – это путь в одну сторону, если место сожрано, но то его назад не вернуть.

    В итоге большинство серверов болтаются где то у границы 90% space used – именно потому, что на границе 90% срабатывает алерт. Как только я даю немного, именно немного места – сервер отправляется в район 80%-85% used, и через месяц другой место надо добавлять снова. И, тем не менее, много сразу давать не буду – слишком много прецедентов с runaways.

    Я так часто делал механическую работу по расширению места на дисках, что мне это надоело и я решил это автоматизировать с помощью Jenkins:



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

    Разумеется, прежде чем добавлять место я смотрю историю роста space used %, автоматически приложенную к алерту моей тайной системой мониторинга. Чаще всего рост естественный:



    А вот тут лучше вначале разобраться:



    Вернемся к Jenkins, который есть лишь интерфейс к Powershell script. У нас много VMware Vcenters, так что специальная процедура на SQL по имени сервера определяет, где находится данный сервер и коннектится именно к нему:



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



    Правда, я нагло пользуюсь тем, что все сервера у нас отлиты подобным образом, например, D: всегда Hard disk 2. Если у вас это не так, то придется помучиться.

    Теперь диск расширен с точка зрения VMware, но не с точки зрения guest (Windows). Мы должны выделенное место использовать. Для этого надо выполнить внутри guestа команды DISKPART.



    Мы нагло запихиваем в корень D: файл BAT и IN, и с помощью WMIC заставляем машинку выполнить эти команды. Файл doresizeX.bat (X – название драйва) содержит лишь
    diskpart <d:\doresizeX.in >d:\doresize.out

    А doresizeX.in содержит:
    rescan
    select volume X
    extend
    exit

    Теперь все готово, надо только чуть подождать (команда то асинхронная!) и прочитать результат, отфильтровав ненужное:



    И ждем письма от Jenkins:

    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 26

      +2
      «Если им заранее выдать много места, то будет обязательно какой нибудь “runaway”, типа апгрейда с переливом таблиц, который пожрет все это место, а если не пожрет, то поднадкусает. Как вы знаете, thin provisioning – это путь в одну сторону, если место сожрано, но то его назад не вернуть. » — и что? Что в этом ужасного? Стоимость ГБ снижается, почему админ решил, что нужно место «зажимать»? Если это клиенты, они за место заплатят, если внутренние подразделения у них тоже могут быть резоны и они могут сами позаботится о бюджете.
      Сисадмин типа красава, экономит место. А базовики извращаются из-за нехватки места, чтобы выполнить свои задачи, потому, что админ ощущает себя «раздающим ресурс».
      С нашими, на текущем месте работы тоже боремся.
      Первый раз столкнулся с таким, что место на дисках для работы БД жмут, админ апологет религии автора статьи, похоже.
      Вопрос: У тебя бюджета не хватает, чтобы диски нарастить? Давай напишу заяву, бюджет выделят. Нет, он считает, что много места, это зло, базовики захапают все равно, поэтому выделять нужно по чуть чуть.
      Как итог регулярные остановы, когда место закончится на диске и база встает. И авральное добавление место по ночам. Какие то БД оперативные удалось проломить твердолобость и увеличить место в разы, а какие то (отчетные, архивные) приходится работать частями. Компания типа «бирюзовая», договаривайтесь мол сами, самоорганизуйтесь, блин. В итоге базовики машут руками и извращаются.
        +4

        Место на NetApp, а еще и реплицируемом для disaster recovery не просто дорогое, а золотое.


        А бюджетные игры довольно сложны у нас, куда сложнее чем "напиши заяву получишь бюджет"

          0
          Просто наболело. У нас деньги есть. Но нет воли и желания админа.
          Не было бы денег, бюджета, другой вопрос и претензий к админам не было бы, с моей стороны.
          У вас может быть, другая ситуация, обобщать не буду. Хотя в статье причины, по которой место не дается не было обозначено, кроме мыслей сисадмина.
            +3
            Я в целом поддерживаю схему работы автора (возможно акромя тонких дисков под сами базы). Просто потому что если не ограничивать ни базовиков, ни 1Сников — сервера баз данных резко наполняются внезапными бэкапами перед обновлениями, которые никто не спешит удалять, непонятными дубликатами баз, копиями и прочими вещами коих быть на продуктовых серверах не должно. Это создает ненужный беспорядок и потребление. Весь этот избыток вместе с виртуальной машиной улетает бэкапом в какой нить Data Domain или StoreOnce и занимает место в хранилище на весь цикл ротации попутно ухудшая RTO.

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

              Автор решил негативную сторону только со своей стороны. У остальных она осталась. И вы смотрите на это чисто с «сисадминской стороны».
              Как насчет накатить обновление без предварительного бэкапа, потому, что места для бэкапа просто нет?
              А ведь так делают, точно знаю, потому как сроки поджимают, админ где то «решает» свои негативные эффекты и вообще запаришься его уговаривать место накинуть.
              А если нужно сделать разработчикам копии БД для отработки — нет, нельзя, места нет.
              Т.е. в цепочке, производственной, админ выцепил свой кусок и оптимизирует его, не глядя на процесс по всей цепочке.
              Хотя, как вариант, в регламент перед «улетом бэкапа в Data Domain» достаточно добавить шаг проверки его содержания.
              Или бэкапы перед обновлением могут лежать на дисках, которые очищаются после тестов и контрольного срока работы обновления.
              В общем, все решаемо, если не закукливаться в рамках одной лишь «экономии места».
              Да и психологическая проблема. Значимость сисадмина уменьшается, если ему не нужно будет решать, когда выделить немножко места по просьбам трудящихся. А так важный человек, решает, кому, сколько отмерить. ЧСВ растет.
                0
                Как насчет накатить обновление без предварительного бэкапа, потому, что места для бэкапа просто нет?
                Бэкап перед обновлением нужен всегда, в этом нет сомнений. Однако бэкап, внезапно, можно делать не на этот же сервер, а:
                — в сетевую папку;
                — на ленточку;
                — специализированные системы с поддержкой дедупликации на лету (читай DDBoost, Catalyst, etc)
                Сетевая папка прям простейшее и общедоступное решение. При правильной настройке прав в базе, бэкап выполняется кем нужно и именно туда куда нужно. К примеру простым скриптом. Или кнопкой в вебинтерфейсе. Вообще не вижу проблем.

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

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

                Любой процесс взаимодействия между командами должен быть понятен всем сторонам, и никто не должен простаивать из-за коллег. В дополнение, мы делаем так что бы никто не мог сломать, даже если бы захотел, то за что мы отвечаем.
                  +1
                  У вас набор противоречивых заявлений:
                  Однако бэкап, внезапно, можно делать не на этот же сервер

                  А с чего вы решили, что на другом сервере место выделено?
                  Мы не экономим место, но мы оптимизируем потребляемые ресурсы по максимуму экономя деньги заказчика.

                  Чистая экономия это бухгалтерский подход. Вы экономите деньги на объеме дисков, и это легко посчитать. Но сколько денег теряется на телодвижениях лишних разработчиков, это уже сложнее и на это частенько забивают. Экономя на дисках, можно потерять темп развития. Что может оказаться гораздо больнее в текущих реалиях.
                  Впрочем я не спорю по поводу вашего подхода. Дьявол кроется в деталях.
                  Вполне может быть, что я экстраполирую мой опыт в текущей организации, когда меня так зажали по дискам, что очень много времени уходит, на то, что бы работать в текущих объемах, а вы свой опыт в текущей организации, с проблемами, которых я не знаю.
                  Но! Когда то бились за каждый кб в памяти, сейчас этого нет и думаю ситуация со временем не поменяется. Места нужно будет больше и больше и ГБ места будет дешевле и дешевле, это нужно учитывать и вовремя расширяться, без фанатичной экономии места на дисках, в ущерб развитию.
                    0
                    >Вы экономите деньги на объеме дисков
                    Диск диску рознь. У нас часто жалуются — вот ты жмотишься 100Gb дать, да я 1Tb в магазине за копейки возьму. Приходиться объяснять что netApp с лицензиями, DR replication (умножить место на 2) плюс 24 снэпшота (умножить непонятно насколько с учетом дельт и дедупликации) совсем другое дело

                    Поэтому все бэкапы «на всякий случай» — на шары на дешевых файловых помойках
                      0
                      У нас часто жалуются
                      — вот ключевые слова. Себе вы жизнь упростили, остальные «часто жалуются».
                      Понимаете, начинать статью нужно было так: «При дефиците финансирования, средств на расширение дисков не хватает, поэтому...».
                      Но у вас этого нет.
                      У нас, руководство заявляет: У ИТ — бюджетный безлимит. Нам нужно, что бы все бегало без запинки, в средствах не ограничиваем.
                      Но у сисадминов, свое видение. И идут «частые жалобы».
                      Ситуация другая совсем.
                      В других компаниях, где я работал, мы (базовики) выдвигали требования по объему, согласовывали бюджет, деньги выделялись и размер дисков не был узким местом и «частых жалоб» не было. Редких тоже.
                      Проходило время, мы ощущали, что начнется напряг с дисками и цикл повторялся.
                      И не было ситуации, когда, например сотрудник аутсорсера запустил чистку БД 1С, сделал удаление циклами по 10 млн. лог разбух и база встала. Не хватило 5-10 гб на диске. Конечно это ночью. Склад встал. Комплектация в магазины встала. Отгрузка машин встала. Суета, нервы, перезвоны.
                      Зато сисадмин сэкономил диски, хотя его об этом никто не просил.
                      Таже фигня с темпдб рабочего сервера.
                      Пока стрелки за остановки на админов не перевели, не желали выделять место для лога. Им казалось, что достаточно и так.
                      Вы из своего уютного мирка выйдите, сходите на остановившееся производство и послушайте, что об вас (ИТ) говорят во время, когда база встала. Может взглянете на мир по другому.
                      А то, кругом враги, желающие все «ваше» место отобрать.
                      Впрочем если вам навесили KPI экономии места, тогда да, ваши действия отлично вписываются в систему.
                        0
                        Бюджетный безлимит? Ну значит вы в раю
                        У нас не то чтобы ограничены средства, но если каждому давать — то развалится бизнесы окажутся неприбыльными

                        Что касается событий, когда место кончилось — то да, при экономии таких событий потенциально больше, но у нас и саппорт реагирует на алерты 24/7 еще на подступах, при 90%
                      +1
                      Не вижу противоречия.
                      Да. Мы экономим деньги заказчика не давая создавать непонятные копии баз данных в которых работает один человек или складировать бэкапы внутри виртуалок расположенных на allflash массивах. Они очень быстрые, но очень дорогие, и их нужно использовать рационально.

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

                      я экстраполирую мой опыт в текущей организации
                      Ну, главное не терять веру в людей. И уметь писать техзадания.
                        0
                        Да. Мы экономим деньги заказчика не давая создавать непонятные копии баз данных в которых работает один человек или складировать бэкапы внутри виртуалок расположенных на allflash массивах. Они очень быстрые, но очень дорогие, и их нужно использовать рационально.

                        А заказчик об этом просил?
                        Нисколько.

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

                        Так вы в реальности выделяете место, столько, сколько нужно, по запросу, о чем тогда спор вообще?
                        И кстати:
                        А обработка запроса это не работа человека, которая денег стоит?
                        Или ожидание обработки запроса, когда кто то простаивает и ждет выполнения запроса, это не потери?
                        И потом, почему вы решили, что я говорю про прод? Мне жмут место везде.
                        Реальная причина моих проблем — админам нужно совершать телодвижения, что бы изменить инфраструктуру и нарастить место серьезно. Допускаю, что у них нет ресурсов человеческих для этого, но этот вопрос нужно поднимать. Я как внутренний клиент очень не доволен сервисом, предоставляемым мне.
                        Я напишу любое требуемое техзадание. Но этого от меня не требуют. Мне просто ограничивают ресурс, от чего страдает дело.
                        На работе мне нужна не вера в людей, а четко настроенные процессы, что бы я занимался своим делом, а не преодолевал устроенные мне искусственные трудности.
                        В данной ситуации, мне нужно место, я делаю заявку, мне говорят, что бы удовлетворить нужен такой то бюджет, я согласовываю расходы с лицом, принимающим решение, и все, поехало. Я так это вижу.
                        А не ходить уговаривать сисадмина проникнутся моими проблемами.
                        Когда то я работал нач. управления бизнес процессов, и мы периодически наталкивались на такую психологию собственника ресурса, когда кто то заполучив ресурс жал его. Типа не желания выписать дополнительные коробки со склада, оправдывая это некоей «экономией», не понимая при этом потребности бизнес подразделений. И убрав такие «мини плотины» бизнес бежал быстрее.
                          0
                          Эскалируйте на начальника, повторять вплоть до директора если проблема не решается. Если и директор жмет Вам место, продолжайте страдать.
                            0
                            Да никто не страдает. Свои проблемы я решу. Сисадмины получили пару раз по голове, с обещанием на третий раз лишиться денежных знаков или работы и стали вдруг добрее и отзывчивее. Это решаемо все, хотя и не приятно этим заниматься.
                            Что печалит: Некоторые товарищи считают себя выше других. Другие, мол, пользователи, они такие бестолковые, что забивают все место всякой не нужной на взгляд админа фигней и их нужно как малых детей контролировать и не пущать. Гордыня и высокомерие. Вот это расстраивает, отношение. Что недостаточно обычных рабочих отношений, обязательно нужно с кнутом приходить, что бы тебя услышали некоторые товарищи. А у админов это наверное проф. деформация, как говорится, развивается.
                            Ну ладно, это снова наш частный случай.
                            Успехов вам в новом году ;)
                    0
                    Бэкапы надо делать у нас на специальные файловые шары. нет ничего хуже чем бэкап сделанный локально — netApp хранит 24 снэпшота дисков плюс все это реплицируется в другой датацентр. Поэтому бэкапы на локальные диски я запретил на уровне MS SQL
                    +1
                    «что если не ограничивать ни базовиков» — спасибо, видно что вы тоже все это вкусили
                  0
                  Как вы знаете, thin provisioning – это путь в одну сторону, если место сожрано, но то его > назад не вернуть.

                  С каких это пор? NetApp поддерживает space reclamation.

                    +1
                    Space Reclamation на моей памяти работает на уровне thin provisioning LUNов презентованных в виртуальную машину, а не на конкретных thin provisioning дисков vhdx/vmdx файлов лежащих на датосторе/луне.
                    Автор, скорее всего, говорит о типичной проблеме с thin provisioning связанной с тем, что выдав терабайт тонкого диска и записав терабайт данных в него ты начинаешь занимать на датасторе терабайт. Почистив место внутри виртуальной машины, допустим даже сжав раздел файловой системы до 100 оставшихся гигов данных — тонкий диск сам по себе меньше не станет занимать на датосторе. Нужны операции обнуления секторов внутри машины с последующей миграцией на другой датастор, либо остановка диска (читай и виртуалки) для выполнения операции высвобождения места на датасторе. А эти операции не всегда возможны.
                      0
                      Именно. Если же учесть, что речь идет о файлах базы, открытых exclusively by MS SQL — сжатие как минимум требует downtime.
                        0

                        В случае с NetApp нет необходимости что-то останавливать и/или забивать нулями. Всё работает автоматически.
                        В случае SAN https://habr.com/ru/post/271959/
                        В случае NFS вообще нет такой проблемы.

                          0
                          Статью не видел, спасибо. Буду знать. Чеклист не слишком приятный, увы.
                          Только из второй половины статьи не понятно: Если в виртуалке осталось 100 гигов из терабайта на диске, то в свойствах виртуальной машины после процедуры очистки будет показывать что занято на луне 100 гигов из возможного одного терабайта?
                  +1

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

                    0
                    Тоже овер сотня серверов бд с линукс и тоже место не везде можно выдать побольше и сразу. Отчасти потому что схд несколько и бюджет не везде заложен, а также из-за того что сожрут и не подавятся. Но все на мониторинге остановов по причине нехватки места почти никогда не бывает.
                      +2
                      К сожалению «вынужден» поддержать автора.

                      Основная проблема (по моему локальному опыту) в том что «не админ» считает что «место — его, и только. Тчк». Достаточно эгоистичное мнение (обычное явление). И «моя потребность/желание» == «потребность бизнеса». Тут-же начинаются разговоры о бюджетах (которые заключаются не только в стоимости дисков). И кто вообще сказал что эти персоны могу говорить о бюджетах? Они их знают, планируют со всеми косвенными тонкостями, учавствуют в утверждении?

                      Тут важно понимание, что это не пинг-понг. «Мы команда» (вы ведь команда, правда?) не в плане «мы хотим — вы делаете», а в плане «бизнес крутится всегда» совместными усилиями. Это система противовесов.
                      Да, все люди и соотв. «админы» могут накосячить и «место нежданно кончилось, все встало». Также как и часто слышал от «не админов» (не дословно, описываю подход) «мы всегда делали копию базы на потом посмотреть и на всякий случай» и тут место кончилось, «нам места недодали»… Дайте нам больше места! Нам, художникам, надо много-много места!
                      В случае с «админами» косяки можно решить всякими алертами с 24/7 и планированием/распределением ресурсов.
                      В случае с «не админами» — только разными блокировками и ограничениями (без фанатизма). Честно, ни в одной компании я не видел чтобы «самодисциплина и самоорганизация потребителей ресурса» тут помогала.

                      Про наболевшее, немного:
                      И пожалуйста, не надо начинать про «20 минут мысли (или даже работы) не админа стоят дороже любого железа/работы других команд». Утрировано, просто пример.
                        +1
                        >Честно, ни в одной компании я не видел чтобы «самодисциплина и самоорганизация потребителей ресурса» тут помогала.

                        Я тоже
                        Кое для чего мне пришлось написать некую самописную полиси в MS SQL — уговоры и объяснения были бесполезны… После нового года опишу это
                        0
                        Сурово вы: не всякая ФС хорошо себя чувствует при относительно небольшом размере (десяток-другой процентов) свободного места. Причем именно разговор о процентах, а не об абсолютном значении, что на современных винтах в террабайты размеры выглядит перебором, но все же.

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

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