28.05.2020 21:15
OlegON
 
Мне казалось, что тема разжевана приблизительно миллион раз, но, тем не менее, общего чего-то и сведенного в одну тему, чтобы отдать нуждающимся, я не нашел. Попробую заново. Итак. Говорим не о какой-то мелочи вроде сервера магазина на трех человек, где можно хоть на десктопе поднимать, а о чем-то серьезном.

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

Если не испугались - идем дальше. Если вы выбираете сервак для офиса и в рост, выбирайте под Linux. Моя рекомендация, если уж читаете тему, то просто поверьте. Большие базы под виндой работают плохо. Вот, тему я начал, никто не поддержал, но просто поверьте, глюков под виндой просто адово количество. "Под Linux" обозначает, что дрова для всех железок этого сервера должны быть в Linux, а сам производитель поддерживает эту операционку. Увы, меня можете не спрашивать, я по железу конкретный вариант не подскажу, просто не успеваю отслеживать тему.

Если надумаете планировать архитектуру, не валите все на новый сервер, планируйте, что все приложения останутся на старом сервере, а на новый переедет только база. И, упаси расчитывать на виртуалки. Тему я подзабросил, но у меня клиент есть, кто пользуется серьезными виртуалками на серьезном оборудовании для СУБД, работает терпимо, но глюки попадаются и непонятно, зачем это терпеть. Были одни странные люди, которые плодили все приложения на виртуалках еще и в Hyper-V, там вообще ужас творился.

В общем, соориентировал: железо без виртуалок, Linux.

Переходим к характеристикам.

Учтите. Какого-то универсального уравнения тут не может быть, поскольку все зависит от нагрузки и даже если вы будете ее мониторить месяц, вылавливая пограничное значение, то выяснится, что квартальная или даже годовая нагрузка поставит сервер на колени. Берите с запасом.

Память
Начнем с памяти, поскольку это самое простое. Сколько у вас бюджета есть, столько и отдайте памяти (ну, понятно, что превышать размер самой БД нет смысла). Сейчас она не столь дорога и у меня в среднем клиенты используют сервера с 256Гб-512Гб памяти, те, самая большая инсталляция использует 1Тб памяти (база 11Тб).
Резюме: сколько можете, столько и ставьте.

Процессоры
Берите максимально доступную производительность по ядрам. Лучше меньше ядер с большей частотой, чем больше ядер с меньшей. Если вы думаете, что пусть они чуть помедленнее, но будут считать в 32 потока, чем быстро, но в 16, то заблуждаетесь. Различные накладные расходы и блокировки сильно удорожают одновременное выполнение в кучу потоков. Берите топовые по частоте ядра. Но, если даже на топовых вам нужно одновременно поддерживать 32 потока, то берите 32 ядра, а не 16. Лучше еще больше - всегда планируйте запас. Не расчитывайте, что у вас одно ядро будет обслуживать десять одновременных запросов. Как только начинаете экономить, сразу приходите к тому, что рост накладных расходов ... и сервер захлебывается, выращивая очередь клиентов и в итоге переходя только в обслуживание этого хаоса больше, чем в полезную работу.
Резюме: Топовые по частоте, количество ядер определяется количеством активных процессов (это не только пользователи).

Носители
Есть достаточно шустрые диски (HDD). Однако, лучше предпочесть SSD. Не забывайте, что помимо обычного линейной скорости чтения, существует такая характеристика, как IOPS, для современной хранилки под базу она должна быть не ниже сотни тысяч в секунду. Диски тут безнадежно проигрывают твердотельным носителям, поскольку никакая механика такую скорость перемещения головки обеспечить не сможет. Не забывайте и о пропускной способности контроллера, она тоже небезгранична и может стать узким местом при большом количестве носителей, объединенных на одном контроллере. На самой большой инсталляции, с которой я сейчас работаю, база под нагрузкой дает почти 2Тб/с чтения. Так что не бойтесь, большие числа сейчас в моде. Кроме того, не делайте ошибок, выделенные под бекап "мусорно-тормозные" диски могут привести к тому, что вы этот бекап либо забрать не сможете, либо на него просто тупо не будут успевать записываться архивлоги, тормозя запись в основную базу, либо при глобальном падении восстанавливаться с этих дисков придется запредельно долго. И не планируйте, что SSD будут использоваться более чем на 60%. Запас все равно нужен, а при заполнении более 80% все SSD начинают тупить записью до неприличия.
Резюме: Большие SSD. Больше для базы, чтобы собрать какой-нибудь 10 рейд, меньше - для бекапа.

Сеть
Я не знаю нормальный сервер, где бы было меньше двух гигабитных карт. Но, если вдруг будут варианты, то именно две гигабитки или более (я не в курсе моды, но 10Гб-карточки тоже ставят). Объедините их потом бондингом, все будет красиво.

Прошу вопросы и замечания...
29.05.2020 00:48
baggio
 
1. забудьте про write cashe на ssd
2. Если есть контроллер с кэшем то под write cahse не менее 50% ram от контроллера... иначе нет смысла...
3. Виртуалки можно если у вас до 100 сессий и приличный сервер... ESXI наще все...
4. План восстановления должен быть на бумаге... и в него должен быть посвящен не 1 человек...
5. Проверяйте целостность бэкапов не реже чем 1 раз в месяц...
29.05.2020 06:52
OlegON
 
Про ESXI в том числе, не больше 50 сессий, т.е. не больше 10 пользователей Супермага, например.
С остальным согласен, только мы про выбор сервера и для ЦО...

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.