Товарищи, прошу дельного совета.Итак ситуация такая, что надо строить сервер для БД. Посмотрел стоимость новых серверов, все от 200 тыс. рублей.
В процессе изучения вопроса нашёл варианты Б/У серверов Supermicro, и они значит практически все на Xeon'ах 2010 года. Например X5680.
Так вот вопросов несколько:
1. Стоит ли брать Б/У сервер двухсокетный на таком процессоре?
2. Стоит ли под БД делать схему хранилища такую: 2xHDD + 2xSSD, где зеркало на HDD'ах под систему, а зеркало на SSD'ах под БД.
3. Какое примерно % соотношение желательно для RAM и объёма БД?Вопрос про схему хранения заключается в том, что SSD же желательно поменьше дёргать на запись, и если SSD в зеркале, то они и на запись одинаково будут "истощаться", это в плане отказоустойчивости вообще имеет смысл?
И если у сервера например ОЗУ 96Гб, при размере БД 16Гб, то не будет ли постоянно что-то писаться на диск?
гадалок здесь нетначнём допрос:
что за движок бд?
> гадалок здесь нет
> начнём допрос:
> что за движок бд?Прошу прощения за неполное описание задачи.
Подниматься будет FreeBSD + MariaDB
Это планирует быть сервер БД для внутренней срм системы с документооборотом и т.п.
Предварительные оценки по объёму БД (заполнил 1 папку документов и экстраполировал на хранящиеся папки) показали что объём БД предполагается изначальный около 16 Гб, хотя это заниженная оценка я сейчас понял. Но порядок точно этот.Т.к. опыта эксплуатации выделенного сервера БД не имею, до этого всё как то писючные комбайны ОС+веб сервер+БД+почта и т.п., то и решил проконсультироваться с имеющими опыт вами.
> И если у сервера например ОЗУ 96Гб, при размере БД 16Гб, то
> не будет ли постоянно что-то писаться на диск?При таком раскладе юзай MySQL и MEMORY storage engine. Или вообще NoSQL и не парь никому мозг.
>> И если у сервера например ОЗУ 96Гб, при размере БД 16Гб, то
>> не будет ли постоянно что-то писаться на диск?
> При таком раскладе юзай MySQL и MEMORY storage engine. Или вообще NoSQL
> и не парь никому мозг.NoSQL вариант не смогу использовать, просто потому что ПО для которого внедряю сервер БД заточено на MySQL.
MEMORY storage engine наверное тоже не решусь, потому как в комментарии выше написал что это сервер БД для корпоративной системы документооборота, покупать думаю Б/У сервер, и не хотелось бы из-за сбоя питания или ещё какой неуместной случайности получить серьёзные проблемы с БД. Так что в качестве движка останется InnoDB.
Если не хочешь из-за сбоя питания или ещё какой неуместной случайности получить серьёзные проблемы с БД, то придется таки брать 2 сервера.На одном можно использовать MEMORY storage engine, а второй как реплику, с которой периодически бэкапы снимать.
И не забудь, что серверы должны быть разнесены географически.
И да, ссд в такой схеме лишние.
По поводу второго сервера для репликации на него базы - да, я его запланировал. Просто в вопросе производительности он же не играет особой роли. Он же просто как постоянная копия базы, ну и в случае падения основного сервера, может принять на себя роль сервера БД.Опять же посмотрел на ключевые моменты MSE, так вот это хранилище не поддерживает foreign key, а у меня ограничения внешними ключами во всех таблицах.
И там же на сайте mysql.com написаны типичные случай когда стоит использовать mse - быстрый доступ к не шибко важным данным типа данные сессий, а в случае когда данные важны то говорят лучше присмотреться к варианту Mysql Cluster, что для моего случая избыточно.Спрошу тогда так: В случае большого объёма ОЗУ, и правильной настройки сервера MySQL, надо ли быструю дисковую подсистему или БД все данные держит в памяти а на диск лишь пишет изменения в БД?
В моём случае большая часть операций БД - это чтение, т.е. SSD для такого случая не обязательно. Хорошо.
А к вопросу о выборе Xeon 56xx, достаточной ли он производительности? Или стоит лучше глядеть на Xeon E5 26xx?
> Опять же посмотрел на ключевые моменты MSE, так вот это хранилище не
> поддерживает foreign key, а у меня ограничения внешними ключами во всех
> таблицах.Foreign keys при правильной работе приложения не играют никак. Они только мешают делать глупости на этапе разработки и отладки.
> mse - быстрый доступ к не шибко важным данным типа данныеИменно - оперативное хранилище. А долговременным пусть служит второй сервер, там можно даже индексы поотключать. Можешь даже оба сервера на одном компьютере гонять.
Начальный запуск будет такой - включаешь оба сервера, выключаешь репликацию. Вытаскиваешь данные с HDD в память, включаешь репликацию.
Не следует путать важный вид начальника и важные данные. Если ты смотришь на б/у сервер, да ещё и на один, значит тебе не важна гарантия. Никакой HA не предусматривается. Значит не очень-то эти данные и важны - не те деньги.
> А к вопросу о выборе Xeon 56xx, достаточной ли он производительности? Или
> стоит лучше глядеть на Xeon E5 26xx?Достаточной - тебя будут тормозить диски и шина PCI, а не процессор.
> Достаточной - тебя будут тормозить диски и шина PCI, а не процессор.А где там используется шина PCI? Какие устройства на ней висят?
А вот если диски будут тормозить, то их как раз и можно будет проапгрейдить до SSD.Спасибо всем за комментарии!
>> Достаточной - тебя будут тормозить диски и шина PCI, а не процессор.
> А где там используется шина PCI? Какие устройства на ней висят?На ней висят все устройства. В рекламе её называют PCI-E, PCIe и PCI Express, что не одно и то же, а только запутывает. Скорее всего под диски и сетевые контроллеры там PCIe 2.0 x4, 2GB/s, что совсем немного.
> А вот если диски будут тормозить, то их как раз и можно
> будет проапгрейдить до SSD.Там от задачи зависит, но ещё раз - под мелкую задачу можно не париться.
Бери любой сервер, ничего особого делать не нужно. 16GB данных - это семечки даже для ноутбука.
Что нужно делать - это backup, причём проверить его. То есть время от времени восстановить backup на другой сервер, чтобы утром все работали на восстановленной копии.А то будет, как с gitlab.com
> Не следует путать важный вид начальника и важные данные. Если ты смотришь
> на б/у сервер, да ещё и на один, значит тебе не
> важна гарантия. Никакой HA не предусматривается. Значит не очень-то эти данные
> и важны - не те деньги.Ну, это философский вопрос:) То что допустим ты отвечаешь за более важные с твоей точки зрения данные, совсем не значит что данные за которые отвечаю в моей ситуации менее важны.
В итоге что ты вылетишь с работы при потере данных, что я. Учитывая что ты видимо птица более высокого полёта, то и средств ты заработал на жизнь приличней моего, и получается что в случае потери данных ты потеряв своё место остаёшься обеспеченным, а я потеряв свои данные вылетаю с работы и судорожно думаю как мне платить ипотеку без работы, да и как устроиться на работу имея в качестве рекоммендации с последнего места работы "волчий билет" :)
При таком раскладе, получается что мои данные поважнее твоих будут, по крайней мере для меня :)
> Ну, это философский вопрос:) То что допустим ты отвечаешь за более важные
> с твоей точки зрения данные, совсем не значит что данные заЯ отвечаю за то, чтобы система могла работать. Причём я не гарантирую, что она будет работать - слишком уж много там намешано от электричества до дятлов-юзверей.
Я не отвечаю за данные, за них отвечают операторы backup и сами юзеры. А они не отвечают за систему - если что-то не работает, то они задают вопрос мне.
>[оверквотинг удален]
> которые отвечаю в моей ситуации менее важны.
> В итоге что ты вылетишь с работы при потере данных, что я.
> Учитывая что ты видимо птица более высокого полёта, то и средств
> ты заработал на жизнь приличней моего, и получается что в случае
> потери данных ты потеряв своё место остаёшься обеспеченным, а я потеряв
> свои данные вылетаю с работы и судорожно думаю как мне платить
> ипотеку без работы, да и как устроиться на работу имея в
> качестве рекоммендации с последнего места работы "волчий билет" :)
> При таком раскладе, получается что мои данные поважнее твоих будут, по крайней
> мере для меня :)Гдето тут есть подвох....
С таким отношением - первый вопрос который вы должны себе задать - где и как вы будете покупать блок питания/процессор взамен вскорости сгоревшего, для того БУшного барахла которое купите...
Причем надо полагать за свои деньги....
Потому что корпоративная база данных и проблема выделить 200к за сервер - намекают на некие сомнения...
Вы с таким трепетом бережете деньги предприятия, и так трясетесь из-за потери данных...
И не надо говорить что вы все понимаете, но денег директор не выделяет...
да-да!
бывает приходишь такой к директооу и говоришь - дай денег на новый сервер!
а он в ответ - денег нет, но вы там держитесь! а если что случится - я спрошу с вас!
удачи всем и хорошего настроения!
> Потому что корпоративная база данных и проблема выделить 200к за сервер -
> намекают на некие сомнения...За 200к можно купить 3-4 бу сервера. Первые 2 под мастер/бэкап, остальные в зип на запчасти.
А вот где вы предлагаете брать деньги на запчасти или продление гарантии для нового "супернадежного" сервера в единственном экземпляре за 200к?
> А к вопросу о выборе Xeon 56xx, достаточной ли он производительности? Или
> стоит лучше глядеть на Xeon E5 26xx?сервер на паре X5650+ по производительности вполне достаточен для любого офисного применения, где кол-во юзеров <50.
К сожалению, кол-во пользователей системы не оглашено. Но по другим вводным данным можно предположить, что их человек 20-30. Вариант с 2хHDD и 2xSSD вполне разумен. Естественно, обязателен бекап на внешний носитель (пока нет второго сервера - то чем чаще, тем лучше - уточните у руководителя - данные за какое время работы вы можете потерять) . SSD берите нормальные только (для серверов), не надо брать жесткий noname :)
>> А к вопросу о выборе Xeon 56xx, достаточной ли он производительности? Или
>> стоит лучше глядеть на Xeon E5 26xx?
> сервер на паре X5650+ по производительности вполне достаточен для любого офисного применения,
> где кол-во юзеров <50.
> К сожалению, кол-во пользователей системы не оглашено. Но по другим вводным данным
> можно предположить, что их человек 20-30. Вариант с 2хHDD и 2xSSD
> вполне разумен. Естественно, обязателен бекап на внешний носитель (пока нет второго
> сервера - то чем чаще, тем лучше - уточните у руководителя
> - данные за какое время работы вы можете потерять) . SSD
> берите нормальные только (для серверов), не надо брать жесткий noname :)Пользователей на данный момент 60-70, а по поводу бэкапа - это конечно. Я ж не вчера за администрирование сел. Давным давно был научен случаем после которого уже делаю бэкапы :)
По поводу бэкапов, то я воспользуюсь схемой с slave сервером, с которого ещё ежечасные DUMP'ы баз сниматься будут.
И у руководителя мне спрашивать такую информацию точно не придётся. Я ж специалист по этому вопросу. Мне кажется мой начальник подумает что я немного того, если я к нему приду за советом как бы мне организовывать бэкап, чтобы потерять если что день работы или два. :)
А на серваке всё-же решил остановиться на базе E5-ых хеонов. Разница в стоимости вообще невелика, а поколение новое да и ядер поболе.
> А к вопросу о выборе Xeon 56xx, достаточной ли он производительности? Или
> стоит лучше глядеть на Xeon E5 26xx?БД это в первую очередь работа процессор память, в этом плане:
E5 2690 vs x5680 - просто небо и земля, это 21K против 9K,
открой для себя сайт https://www.cpubenchmark.net
1. нет и вообще не покупайте б/у серверы, лучше соберите машинку из десктопного железа
2. да, используйте ссд для всего, кроме холодного хранилища больших файлов
3. памяти много не бывает, желательно чтобы бд "помещалась" в память. Должны помещаться как минимум индексы.
> SSD же желательно поменьше дёргать на запись,Забудьте про это. Ресурс SSD уже на уровне обычных. Хреновые харды летят быстрее, чем ссд без всякой нагрузки.
>это в плане отказоустойчивости вообще имеет смысл?
Имеет. У одного может выйти из строя контроллер. Рейды имеют смысл всегда, как и бэкапы.