Построение оптимальной :) системы для Базы Данных (из чего)?
Модераторы: Trinity admin`s, Free-lance moderator`s
Построение оптимальной :) системы для Базы Данных (из чего)?
Добрый день.
Сразу оговорюсь есть некие теоритические знания, но практического опыта (по кластерам) ни какого... так, что сильно не пинайтесь
-------------------------------------------------------------------------------------
Исходное: В разработке БД на платформе MSSQL2K.
Стартовый объём ~100Гб, через пол года после старта ~300Гб
и в дальнейшем прирост ~300-500Мб в сутки.
В оперативной базе актуально держать данные только за последний месяц остальное сливать в хранилище
к которому сбоку будет прицеплен OLAP и репортинг.
Устойчивость максимально возможная 09-21 шесть дней в неделю.
Поднятие в случае ахтунга в пределах не более 5 минут.
Предполагаемая система бэкапирования: фулл раз в сутки + дифы и лог так часто как позволит "мать природа". Хотелось бы фулл ещё и в середине дня, но при таких объёмах понимаю, что не потянет...
(основная задача отресторить с точностью "до ms").
-------------------------------------------------------------------------------------
Дак вот... посмотрев на всё это "хозяйство" задумался о кластере из двух узлов для оперативной базы и отдельный сервак под хранилище и возможно ещё один для репортов(предполагается нагрузка).
Но как уже говорил практического опыта в данной области нет и поэтому помогите советом как бы это всё организовать(кластер + SAN).
И на сколько всё это потянет по деньгам(+/- конечно).
Спасибо. :?:
Сразу оговорюсь есть некие теоритические знания, но практического опыта (по кластерам) ни какого... так, что сильно не пинайтесь
-------------------------------------------------------------------------------------
Исходное: В разработке БД на платформе MSSQL2K.
Стартовый объём ~100Гб, через пол года после старта ~300Гб
и в дальнейшем прирост ~300-500Мб в сутки.
В оперативной базе актуально держать данные только за последний месяц остальное сливать в хранилище
к которому сбоку будет прицеплен OLAP и репортинг.
Устойчивость максимально возможная 09-21 шесть дней в неделю.
Поднятие в случае ахтунга в пределах не более 5 минут.
Предполагаемая система бэкапирования: фулл раз в сутки + дифы и лог так часто как позволит "мать природа". Хотелось бы фулл ещё и в середине дня, но при таких объёмах понимаю, что не потянет...
(основная задача отресторить с точностью "до ms").
-------------------------------------------------------------------------------------
Дак вот... посмотрев на всё это "хозяйство" задумался о кластере из двух узлов для оперативной базы и отдельный сервак под хранилище и возможно ещё один для репортов(предполагается нагрузка).
Но как уже говорил практического опыта в данной области нет и поэтому помогите советом как бы это всё организовать(кластер + SAN).
И на сколько всё это потянет по деньгам(+/- конечно).
Спасибо. :?:
- gs
- Сотрудник Тринити
- Сообщения: 16650
- Зарегистрирован: 23 авг 2002, 17:34
- Откуда: Москва
- Контактная информация:
Что касается арихтектуры, то требования диктуются временем простоя достаточно однозначно - это кластер из двух машин под собственно базу, плюс под олапы. И плюс две зазеркаленные дисковые системы.
Стоить это будет по самому оптимистичному прогнозу от 50 тонн до нескольких сотен - класс железа зависит от нагрузки, с которой пока не все ясно.
Вопросы:
1. Число юзеров отдельно транзакционной базы и олаповой.
2. Не очень ясно с размером базы. С одной стороны пишете про 100-300ГБ, с другой про месячные урезания (т.е. месячный объем порядка 10ГБ). Разница колоссальная.
Стоить это будет по самому оптимистичному прогнозу от 50 тонн до нескольких сотен - класс железа зависит от нагрузки, с которой пока не все ясно.
Вопросы:
1. Число юзеров отдельно транзакционной базы и олаповой.
2. Не очень ясно с размером базы. С одной стороны пишете про 100-300ГБ, с другой про месячные урезания (т.е. месячный объем порядка 10ГБ). Разница колоссальная.
1. 300-500 на OLTP, ~50 на OLAPgs писал(а): 1. Число юзеров отдельно транзакционной базы и олаповой.
2. Не очень ясно с размером базы. С одной стороны пишете про 100-300ГБ, с другой про месячные урезания (т.е. месячный объем порядка 10ГБ). Разница колоссальная.
2. Хранилище идёт второй очередью поэтому к моменту его предполагаемого запуска оперативная база будет ~300Гб.
После ввода в работу хранилища оперативная будет содержать только месячный объём максимум за два, а остальное сливаться в хранилище (которое предполагает нулевой уровень агрегации, что накладывает определённые требования...).
Вопрос: насколько разумно для такой системы вести разговор о SAN?
ведь критично не только малое время простоя, но и частые бэкапы не затрагивающие производительность, да и будущее хранилище то-же нужно бэкапить...
- gs
- Сотрудник Тринити
- Сообщения: 16650
- Зарегистрирован: 23 авг 2002, 17:34
- Откуда: Москва
- Контактная информация:
При таких требованиях к времени восстановления бэкап делу не поможет. Он просто спасет при совсем уж какастрофической ситуации. Бэкап просто невозможно накатить за такое время. Тем более что перед этим железку еще починить нада.
В качестве МИНИМАЛЬНОГО варианта стоит рассматривать кластер из двух машин (кстати одна из них может быть оперативной, а вторая олаповой в нормальном режиме. А в случае сбоя обе задачи сядут на выжившую) и внешнюю дисковую систему. От дублирования дисковых собственно можно отказаться (с некоторой потерей отказоустойчивости конечно) в пользу одной двухконтроллерной системы.
На мой взгляд (пока сугубо навскидку), система должна быть примерно такая. Пара серверов типа SUN v40z (или его полный аналог Newisys4300 или новая супермикра) с четырьмя двуядерными оптеронами (памяти гигов по 16) в кластере виндовом. На одном крутится OLTP, на втором OLAP. Дисковая система IBM DS4300 с 40-50 дисками. Лучше дисковая HDS AMS200. Подешевле дисковая Infortrend EonStor F16F-R2021. Собственно из FC оборудования потребуются только адаптеры в сервера - свичи в данном случае особо не нужны.
В качестве МИНИМАЛЬНОГО варианта стоит рассматривать кластер из двух машин (кстати одна из них может быть оперативной, а вторая олаповой в нормальном режиме. А в случае сбоя обе задачи сядут на выжившую) и внешнюю дисковую систему. От дублирования дисковых собственно можно отказаться (с некоторой потерей отказоустойчивости конечно) в пользу одной двухконтроллерной системы.
На мой взгляд (пока сугубо навскидку), система должна быть примерно такая. Пара серверов типа SUN v40z (или его полный аналог Newisys4300 или новая супермикра) с четырьмя двуядерными оптеронами (памяти гигов по 16) в кластере виндовом. На одном крутится OLTP, на втором OLAP. Дисковая система IBM DS4300 с 40-50 дисками. Лучше дисковая HDS AMS200. Подешевле дисковая Infortrend EonStor F16F-R2021. Собственно из FC оборудования потребуются только адаптеры в сервера - свичи в данном случае особо не нужны.
Про то, что бэкап не поднимится на таких объёмах за это время это однозначно и двуядерный кластер без вариантов...
К нему внешний RAID(10) (как это на Ваш взгляд?) общий для обоих узлов зазеркаленый на такой же (на случай ядерной войны).
Как Вам кажется может стоит с самого начала делать завязку на SAN (с учётом будущего хранилища и аналитики как отдельных серверов) для централизации данных и бэкапов?
Вы уже приводили некие варианты по железу, а могли бы озвучить три варианта (минимум, средне, "то что доктор прописал") с указанием моделей и примерным ценником. В разрезе требований и зеркалирования внешних рейдов.
Спасибо.
К нему внешний RAID(10) (как это на Ваш взгляд?) общий для обоих узлов зазеркаленый на такой же (на случай ядерной войны).
Как Вам кажется может стоит с самого начала делать завязку на SAN (с учётом будущего хранилища и аналитики как отдельных серверов) для централизации данных и бэкапов?
Вы уже приводили некие варианты по железу, а могли бы озвучить три варианта (минимум, средне, "то что доктор прописал") с указанием моделей и примерным ценником. В разрезе требований и зеркалирования внешних рейдов.
Спасибо.
- gs
- Сотрудник Тринити
- Сообщения: 16650
- Зарегистрирован: 23 авг 2002, 17:34
- Откуда: Москва
- Контактная информация:
Архитектуру, что я привел, можно наращивать в любую сторону. Это просто минимально рабочий комплект, который можно будет умощнять по мере роста потребностей.
По поводу вариантов - давайте спишемся или созвонимся. Это уже требует рассчетов - да и как я тут спецификацию на два листа воткну?
И еще. Огласите бюджет, пожалуйста. Можно не в открытую. Так просто будет понятнее, что предлагать.
По поводу вариантов - давайте спишемся или созвонимся. Это уже требует рассчетов - да и как я тут спецификацию на два листа воткну?
И еще. Огласите бюджет, пожалуйста. Можно не в открытую. Так просто будет понятнее, что предлагать.
Смотря, что Вы подразумеваете под бэкапом... если ленту, то лента отдельно, а если дисковые бэкапы, то хотелось бы уложиться.a_shats писал(а):Вопрос:
Эта сумма на БД+бэкап или только на БД ?
Честно предупреждаю: если без бэкапа, то хватит на честную пару HDS AMS500+TrueCopy и пару Newisys 4300 c "упаковкой" по максимуму. Если с бэкапом - не хватит.
Но опять таки система делается на будущее так что будет нужно (аргументировано) добавим (в разумных пределах).
Спасибо за ответы.
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 7 гостей