Comments 26
UFO just landed and posted this here
Место на NetApp, а еще и реплицируемом для disaster recovery не просто дорогое, а золотое.
А бюджетные игры довольно сложны у нас, куда сложнее чем "напиши заяву получишь бюджет"
UFO just landed and posted this here
Я в целом поддерживаю схему работы автора (возможно акромя тонких дисков под сами базы). Просто потому что если не ограничивать ни базовиков, ни 1Сников — сервера баз данных резко наполняются внезапными бэкапами перед обновлениями, которые никто не спешит удалять, непонятными дубликатами баз, копиями и прочими вещами коих быть на продуктовых серверах не должно. Это создает ненужный беспорядок и потребление. Весь этот избыток вместе с виртуальной машиной улетает бэкапом в какой нить Data Domain или StoreOnce и занимает место в хранилище на весь цикл ротации попутно ухудшая RTO.
Создание ограничения на доступное место устраняет этот эффект, а негативную сторону этой реализации автор весьма эффективно решил. Честь ему и хвала.
Создание ограничения на доступное место устраняет этот эффект, а негативную сторону этой реализации автор весьма эффективно решил. Честь ему и хвала.
UFO just landed and posted this here
Как насчет накатить обновление без предварительного бэкапа, потому, что места для бэкапа просто нет?Бэкап перед обновлением нужен всегда, в этом нет сомнений. Однако бэкап, внезапно, можно делать не на этот же сервер, а:
— в сетевую папку;
— на ленточку;
— специализированные системы с поддержкой дедупликации на лету (читай DDBoost, Catalyst, etc)
Сетевая папка прям простейшее и общедоступное решение. При правильной настройке прав в базе, бэкап выполняется кем нужно и именно туда куда нужно. К примеру простым скриптом. Или кнопкой в вебинтерфейсе. Вообще не вижу проблем.
И вы смотрите на это чисто с «сисадминской стороны».Ну я лично смотрю с позиции корпоративного аутсорсера, который админит множество серверов, включая базоводы, где в каждой организации свой набор 1Сников, техсуппортов и даже админов. Правильно разданные права, строгий подход к контролю ресурсов избавляет меня от ответственности за простой вверенных нам на обслуживание систем. Мы не оправдаемся за простой, тем что Ваши 1Сники наделали бэкапов и все резко встало колом. Мы просто не даем им возможности сломать, но даем возможность делать бэкапы и прочие изменения как им угодно часто поскольку этого требует рабочий процесс.
В общем, все решаемо, если не закукливаться в рамках одной лишь «экономии места».Нас интересует скорость работы сервисов и время их доступности. Мы не экономим место, но мы оптимизируем потребляемые ресурсы по максимуму экономя деньги заказчика. У собственных ИТ команд заказчика эти задачи не являются приоритетными, от них требуется развитие функционала.
Любой процесс взаимодействия между командами должен быть понятен всем сторонам, и никто не должен простаивать из-за коллег. В дополнение, мы делаем так что бы никто не мог сломать, даже если бы захотел, то за что мы отвечаем.
UFO just landed and posted this here
>Вы экономите деньги на объеме дисков
Диск диску рознь. У нас часто жалуются — вот ты жмотишься 100Gb дать, да я 1Tb в магазине за копейки возьму. Приходиться объяснять что netApp с лицензиями, DR replication (умножить место на 2) плюс 24 снэпшота (умножить непонятно насколько с учетом дельт и дедупликации) совсем другое дело
Поэтому все бэкапы «на всякий случай» — на шары на дешевых файловых помойках
Диск диску рознь. У нас часто жалуются — вот ты жмотишься 100Gb дать, да я 1Tb в магазине за копейки возьму. Приходиться объяснять что netApp с лицензиями, DR replication (умножить место на 2) плюс 24 снэпшота (умножить непонятно насколько с учетом дельт и дедупликации) совсем другое дело
Поэтому все бэкапы «на всякий случай» — на шары на дешевых файловых помойках
UFO just landed and posted this here
Бюджетный безлимит? Ну значит вы в раю
У нас не то чтобы ограничены средства, но если каждому давать — торазвалится бизнесы окажутся неприбыльными
Что касается событий, когда место кончилось — то да, при экономии таких событий потенциально больше, но у нас и саппорт реагирует на алерты 24/7 еще на подступах, при 90%
У нас не то чтобы ограничены средства, но если каждому давать — то
Что касается событий, когда место кончилось — то да, при экономии таких событий потенциально больше, но у нас и саппорт реагирует на алерты 24/7 еще на подступах, при 90%
Не вижу противоречия.
Да. Мы экономим деньги заказчика не давая создавать непонятные копии баз данных в которых работает один человек или складировать бэкапы внутри виртуалок расположенных на allflash массивах. Они очень быстрые, но очень дорогие, и их нужно использовать рационально.
Да. Мы экономим деньги заказчика не давая создавать непонятные копии баз данных в которых работает один человек или складировать бэкапы внутри виртуалок расположенных на allflash массивах. Они очень быстрые, но очень дорогие, и их нужно использовать рационально.
сколько денег теряется на телодвиженияхНисколько. Отдельные виртуалки с тестовыми базами не влияющие на прод на ресурсах подешевле. Загрузка любого бэкапа в тестовую инфраструктуру по запросу или расписанию. Отдельные сервера под олап-кубы и генерацию отчетности для финансово экономических отделов.
я экстраполирую мой опыт в текущей организацииНу, главное не терять веру в людей. И уметь писать техзадания.
Бэкапы надо делать у нас на специальные файловые шары. нет ничего хуже чем бэкап сделанный локально — netApp хранит 24 снэпшота дисков плюс все это реплицируется в другой датацентр. Поэтому бэкапы на локальные диски я запретил на уровне MS SQL
«что если не ограничивать ни базовиков» — спасибо, видно что вы тоже все это вкусили
Как вы знаете, thin provisioning – это путь в одну сторону, если место сожрано, но то его > назад не вернуть.
С каких это пор? NetApp поддерживает space reclamation.
Space Reclamation на моей памяти работает на уровне thin provisioning LUNов презентованных в виртуальную машину, а не на конкретных thin provisioning дисков vhdx/vmdx файлов лежащих на датосторе/луне.
Автор, скорее всего, говорит о типичной проблеме с thin provisioning связанной с тем, что выдав терабайт тонкого диска и записав терабайт данных в него ты начинаешь занимать на датасторе терабайт. Почистив место внутри виртуальной машины, допустим даже сжав раздел файловой системы до 100 оставшихся гигов данных — тонкий диск сам по себе меньше не станет занимать на датосторе. Нужны операции обнуления секторов внутри машины с последующей миграцией на другой датастор, либо остановка диска (читай и виртуалки) для выполнения операции высвобождения места на датасторе. А эти операции не всегда возможны.
Автор, скорее всего, говорит о типичной проблеме с thin provisioning связанной с тем, что выдав терабайт тонкого диска и записав терабайт данных в него ты начинаешь занимать на датасторе терабайт. Почистив место внутри виртуальной машины, допустим даже сжав раздел файловой системы до 100 оставшихся гигов данных — тонкий диск сам по себе меньше не станет занимать на датосторе. Нужны операции обнуления секторов внутри машины с последующей миграцией на другой датастор, либо остановка диска (читай и виртуалки) для выполнения операции высвобождения места на датасторе. А эти операции не всегда возможны.
Именно. Если же учесть, что речь идет о файлах базы, открытых exclusively by MS SQL — сжатие как минимум требует downtime.
В случае с NetApp нет необходимости что-то останавливать и/или забивать нулями. Всё работает автоматически.
В случае SAN https://habr.com/ru/post/271959/
В случае NFS вообще нет такой проблемы.
Статью не видел, спасибо. Буду знать. Чеклист не слишком приятный, увы.
Только из второй половины статьи не понятно: Если в виртуалке осталось 100 гигов из терабайта на диске, то в свойствах виртуальной машины после процедуры очистки будет показывать что занято на луне 100 гигов из возможного одного терабайта?
Только из второй половины статьи не понятно: Если в виртуалке осталось 100 гигов из терабайта на диске, то в свойствах виртуальной машины после процедуры очистки будет показывать что занято на луне 100 гигов из возможного одного терабайта?
Вообще-то время полу-заполнения всегда константа, как бы не было большое доступное пространство. Так что выделять понемногу, вполне разумное решение. Только мне кажется, что этот процесс можно и еще более автоматизировать, чтобы скорость заполнения держалась хотя бы в полиномиальных границах...
Тоже овер сотня серверов бд с линукс и тоже место не везде можно выдать побольше и сразу. Отчасти потому что схд несколько и бюджет не везде заложен, а также из-за того что сожрут и не подавятся. Но все на мониторинге остановов по причине нехватки места почти никогда не бывает.
К сожалению «вынужден» поддержать автора.
Основная проблема (по моему локальному опыту) в том что «не админ» считает что «место — его, и только. Тчк». Достаточно эгоистичное мнение (обычное явление). И «моя потребность/желание» == «потребность бизнеса». Тут-же начинаются разговоры о бюджетах (которые заключаются не только в стоимости дисков). И кто вообще сказал что эти персоны могу говорить о бюджетах? Они их знают, планируют со всеми косвенными тонкостями, учавствуют в утверждении?
Тут важно понимание, что это не пинг-понг. «Мы команда» (вы ведь команда, правда?) не в плане «мы хотим — вы делаете», а в плане «бизнес крутится всегда» совместными усилиями. Это система противовесов.
Да, все люди и соотв. «админы» могут накосячить и «место нежданно кончилось, все встало». Также как и часто слышал от «не админов» (не дословно, описываю подход) «мы всегда делали копию базы на потом посмотреть и на всякий случай» и тут место кончилось, «нам места недодали»… Дайте нам больше места! Нам, художникам, надо много-много места!
В случае с «админами» косяки можно решить всякими алертами с 24/7 и планированием/распределением ресурсов.
В случае с «не админами» — только разными блокировками и ограничениями (без фанатизма). Честно, ни в одной компании я не видел чтобы «самодисциплина и самоорганизация потребителей ресурса» тут помогала.
Про наболевшее, немного:
И пожалуйста, не надо начинать про «20 минут мысли (или даже работы) не админа стоят дороже любого железа/работы других команд». Утрировано, просто пример.
Основная проблема (по моему локальному опыту) в том что «не админ» считает что «место — его, и только. Тчк». Достаточно эгоистичное мнение (обычное явление). И «моя потребность/желание» == «потребность бизнеса». Тут-же начинаются разговоры о бюджетах (которые заключаются не только в стоимости дисков). И кто вообще сказал что эти персоны могу говорить о бюджетах? Они их знают, планируют со всеми косвенными тонкостями, учавствуют в утверждении?
Тут важно понимание, что это не пинг-понг. «Мы команда» (вы ведь команда, правда?) не в плане «мы хотим — вы делаете», а в плане «бизнес крутится всегда» совместными усилиями. Это система противовесов.
Да, все люди и соотв. «админы» могут накосячить и «место нежданно кончилось, все встало». Также как и часто слышал от «не админов» (не дословно, описываю подход) «мы всегда делали копию базы на потом посмотреть и на всякий случай» и тут место кончилось, «нам места недодали»… Дайте нам больше места! Нам, художникам, надо много-много места!
В случае с «админами» косяки можно решить всякими алертами с 24/7 и планированием/распределением ресурсов.
В случае с «не админами» — только разными блокировками и ограничениями (без фанатизма). Честно, ни в одной компании я не видел чтобы «самодисциплина и самоорганизация потребителей ресурса» тут помогала.
Про наболевшее, немного:
И пожалуйста, не надо начинать про «20 минут мысли (или даже работы) не админа стоят дороже любого железа/работы других команд». Утрировано, просто пример.
Сурово вы: не всякая ФС хорошо себя чувствует при относительно небольшом размере (десяток-другой процентов) свободного места. Причем именно разговор о процентах, а не об абсолютном значении, что на современных винтах в террабайты размеры выглядит перебором, но все же.
Sign up to leave a comment.
Утро админа: добавляем место на десятках серверов за кофе