Система высокой готовности
Модераторы: Trinity admin`s, Free-lance moderator`s
- TeRminaToR
- Advanced member
- Сообщения: 105
- Зарегистрирован: 07 окт 2002, 20:07
- Откуда: Москва
- Контактная информация:
Система высокой готовности
Уважаемые господа, какой сервер (группу серверов/кластер) вы порекомендуете для выполнения следующих задач? Сразу отмечу, что самое главное - это надежность за разумные деньги. Т.е. полученная система должна гарантировать простои не более 5 минут в день и не более 6 часов в год и в тоже время обладать стоимостью в пределах 10000-20000$. Итак, задачи требующие реализации такие:
1) Файл сервер на 50 пользователей, каждому по 300Мб+20Гб для корпоративной информации. Рост объема хранимой информации +30% в год. Динамически изменяемой информации около 30%, остальное - архивы не требующие высокой скорости доступа, но требующие абсолютно надежной сохранности. 50% архивов обновляются раз в неделю, 20% - ежедневно.
2) Сервер баз данных операционного дня R-STYLE RS-BANK 5 на 30 пользователей под управлением Btrieve или Pervasive SQL.
3) Сервер баз данных системы банк-клиент BSsystems DOS на 5 пользователей под управлением Btrieve или Pervasive SQL
4) Сервер приложений под пункты 2 и 3
5) Сервер терминалов на 50 пользователей под вышеперечисленные задачи
Итак, задача поставлена, давайте вместе подумаем над ее решением. Для начала без конкретики, а лишь в общих чертах (сколько и каких серверов, нужен ли кластер для обеспечения необходимой надежности, нужно ли общее хранилище данных (NAS или RAID стойка) и т.п.). По мере появления вариантов я попытаюсь еще больше конкретизировать условия.
Вариант придуманный мною, а также вариант который работает сейчас, разглошать пока не буду, дабы не направить нас по ложному пути. Мне интересно как бы вы решили подобную задачу...
1) Файл сервер на 50 пользователей, каждому по 300Мб+20Гб для корпоративной информации. Рост объема хранимой информации +30% в год. Динамически изменяемой информации около 30%, остальное - архивы не требующие высокой скорости доступа, но требующие абсолютно надежной сохранности. 50% архивов обновляются раз в неделю, 20% - ежедневно.
2) Сервер баз данных операционного дня R-STYLE RS-BANK 5 на 30 пользователей под управлением Btrieve или Pervasive SQL.
3) Сервер баз данных системы банк-клиент BSsystems DOS на 5 пользователей под управлением Btrieve или Pervasive SQL
4) Сервер приложений под пункты 2 и 3
5) Сервер терминалов на 50 пользователей под вышеперечисленные задачи
Итак, задача поставлена, давайте вместе подумаем над ее решением. Для начала без конкретики, а лишь в общих чертах (сколько и каких серверов, нужен ли кластер для обеспечения необходимой надежности, нужно ли общее хранилище данных (NAS или RAID стойка) и т.п.). По мере появления вариантов я попытаюсь еще больше конкретизировать условия.
Вариант придуманный мною, а также вариант который работает сейчас, разглошать пока не буду, дабы не направить нас по ложному пути. Мне интересно как бы вы решили подобную задачу...
- TeRminaToR
- Advanced member
- Сообщения: 105
- Зарегистрирован: 07 окт 2002, 20:07
- Откуда: Москва
- Контактная информация:
Операционка не определена, сейчас работает под Novell Netware 4.11 и Btrieve 6.15 Также известно, что перечисленный софт работает с Pervasive SQL 2000 реализации которого есть под Novell Netware, Linux и Windows 2000. Так что операционку есть из чего выбирать. Единственное, что пока непонятно, поддерживает ли Pervasive SQL, на котором это потенциально будет работать, кластерную архитектуру и есть ли его реализации под другие ОС, например, FreeBSD.
- CyberDrake
- free-lance moderator
- Сообщения: 338
- Зарегистрирован: 23 авг 2002, 10:39
- Откуда: Санкт-Петербург
- Контактная информация:
Ситстема высокой готовности
Во первых замечание по поводу времени простоя системы. Время простоя определяется не только техникой, а в первую очередь человеческим фактором , и все разговоры о готовности в сколько-то там девяток я считаю бесполезными (по крайней на рынке решений до 1 мегабакса). Кстати, 5минут*365дней=30 часов с копейками:)
Второе замечание об использовании кластера: применение кластера (опять же для этого сегмента рынка) не гарантирует полностью сохранность данных, так как все известные мне кластеры высокой надежности работают по принципу master-slave, и если master, падая, испортит информацию на логическом уровне, то ничего поделать уже будет нельзя.
Остается использовать репликацию на резервный сервер и в случае сбоя восстанавливать базу по журналу транзакций.
С резервного сервера можно также делать резервное копирование на ленты.
А если основной и резервный сервер объединить в кластер....
В общем вариантов куча. хотелось бы порисовать схемки и обсудить их.
Вкратце выводы: два сервера, основной и резервный, на который идет репликация, и они завязаны в кластер с общей дисковой системой, на которой лежат "боевые" базы.
Второе замечание об использовании кластера: применение кластера (опять же для этого сегмента рынка) не гарантирует полностью сохранность данных, так как все известные мне кластеры высокой надежности работают по принципу master-slave, и если master, падая, испортит информацию на логическом уровне, то ничего поделать уже будет нельзя.
Остается использовать репликацию на резервный сервер и в случае сбоя восстанавливать базу по журналу транзакций.
С резервного сервера можно также делать резервное копирование на ленты.
А если основной и резервный сервер объединить в кластер....
В общем вариантов куча. хотелось бы порисовать схемки и обсудить их.
Вкратце выводы: два сервера, основной и резервный, на который идет репликация, и они завязаны в кластер с общей дисковой системой, на которой лежат "боевые" базы.
- gs
- Сотрудник Тринити
- Сообщения: 16650
- Зарегистрирован: 23 авг 2002, 17:34
- Откуда: Москва
- Контактная информация:
С Кибердрейком согласен - минимизировать простой при сбое оборудования можно, но большинство сбоев серверов бывают по причине человеческого фактора.
Навскидку можно предложить два варианта:
1. Кластер (например W2k как самый простой, но, в принципе, они все примерно одинаковы). Дисковая система SCSI-to-SCSI с двумя внешними портами (Fiber не пройдет по цене, да он тут наверно и не нужен) и два сервера. На серверах запустить разные задачи, чтобы вручную сбалансировать нагрузку. В смысле аппаратуры узким местом будет дисковая система, но они достаточно надежны (если только не доэкономиться до Инфортренда).
Сбои дисковой системы бывают крайне редко, но уж если свалится, то пятью минутами не отделаешься. Поэтому кроме бэкапа хорошо бы предусмотреть репликацию оперативной информации на какой-нибудь диск, чтобы в случае чего с него работать.
2. Кластер по русски. То же самое по аппаратуре, но второй сервер держать в холодном резерве сконфигурированным также, как и боевой. Т.е. чистый Standby. Всю изменяющуюся часть информации (базы, логи и т.п.) держать на дисковой системе. В случае сбоя основного, поднять резервный вручную (займет несколько минут). Плюс в том, что не надо тратиться на кластерный софт и никакие вирусы и шаловливые руки не тронут резервный сервак, т.к. он выключен. Да и проще, а значит надежнее, с точки зрения софта. Минус - вся нагрузка ляжет на один сервак. Хотя от повреждения файловой системы на внешнем массиве и это не спасет - поэтому опять же резервный диск с оперативной информацией.
И грамотная политика резервного копирования!!!!!!!!!!!!!!!!
Желательно сначала на диск, а потом уже на ленту - уменьшится простой на время восстановления.
Могут быть и еще варианты, действительно надо конкретнее поговорить...
Навскидку можно предложить два варианта:
1. Кластер (например W2k как самый простой, но, в принципе, они все примерно одинаковы). Дисковая система SCSI-to-SCSI с двумя внешними портами (Fiber не пройдет по цене, да он тут наверно и не нужен) и два сервера. На серверах запустить разные задачи, чтобы вручную сбалансировать нагрузку. В смысле аппаратуры узким местом будет дисковая система, но они достаточно надежны (если только не доэкономиться до Инфортренда).
Сбои дисковой системы бывают крайне редко, но уж если свалится, то пятью минутами не отделаешься. Поэтому кроме бэкапа хорошо бы предусмотреть репликацию оперативной информации на какой-нибудь диск, чтобы в случае чего с него работать.
2. Кластер по русски. То же самое по аппаратуре, но второй сервер держать в холодном резерве сконфигурированным также, как и боевой. Т.е. чистый Standby. Всю изменяющуюся часть информации (базы, логи и т.п.) держать на дисковой системе. В случае сбоя основного, поднять резервный вручную (займет несколько минут). Плюс в том, что не надо тратиться на кластерный софт и никакие вирусы и шаловливые руки не тронут резервный сервак, т.к. он выключен. Да и проще, а значит надежнее, с точки зрения софта. Минус - вся нагрузка ляжет на один сервак. Хотя от повреждения файловой системы на внешнем массиве и это не спасет - поэтому опять же резервный диск с оперативной информацией.
И грамотная политика резервного копирования!!!!!!!!!!!!!!!!
Желательно сначала на диск, а потом уже на ленту - уменьшится простой на время восстановления.
Могут быть и еще варианты, действительно надо конкретнее поговорить...
- TeRminaToR
- Advanced member
- Сообщения: 105
- Зарегистрирован: 07 окт 2002, 20:07
- Откуда: Москва
- Контактная информация:
Давайте будем учитывать только время вынужденного простоя вызванного аппаратным обеспечением сервера или сбоем операционной системы. Ошибки прикладного ПО учитывать не будем, а лишь постараемся максимально возможно их изолировать. Например, будем делать бекап более часто, не раз в сутки, а раз в час. Тогда нужно учесть такую нагрузку на сервер. Выбор интервала бекапа опять же - предмет нашего рассмотрения. Куда складывать бекап - опять же вопрос требующий ответа.
Что касается времени простоя, то 5 минут в день и 6 часов в год не противоречат. Т.е. в случае сбоя аппаратуры или ОС, мне нужна гарантия, что этот сбой я исправлю не более чем за 5 минут. С другой стороны, подобные сбои не долны происходить чаще 1 раза в неделю => 5мин * 52недели / 60 мин = 4,3 часа простоя в год без учета выходных, т.е. в итоге примерно 6 часов. Не такие уж и жесткие ограничения.
Что касается кластера, так я на нем и не настаиваю. У меня полностью отсутствует практический опыт работы с кластерными решениями, поэтому я не могу объективно преставлять себе их возможности по обеспечению отказоустойчивости. Такую информацию я как раз и хотел получить от Вас.
По поводу репликации. На каком уровне производить репликацию ? На уровне NTFS или на уровне баз данных или ??? У меня нет информации по функционированию Pervasive SQL в подобном режиме (а у Вас ?). Что делать с репликациями файловой помойки ? (Опять же какими средствами и насколько они совместимы с остальными задачами, необходимо ли учитывать это сразу или репликации можно настроить позже на произвольный сервер (например, наш старый сервер под Netware). Если мы настраиваем репликации, чтобы обеспечить изоляцию от логических ошибок, зачем нам нам общая дисковая система ?
Кроме того, обращаю ваше внимание, что неизвестно еще как сильно пострадает производительность в случае объединения всех задач на одной машине. У меня нет информации о том, как сильно падает производительность при использовании служб терминалов. Мое мнение, что двух машин здесь явно не хватает... Я не зря (или зря?) вынес серверы приложений в отдельные задачи...
Что касается времени простоя, то 5 минут в день и 6 часов в год не противоречат. Т.е. в случае сбоя аппаратуры или ОС, мне нужна гарантия, что этот сбой я исправлю не более чем за 5 минут. С другой стороны, подобные сбои не долны происходить чаще 1 раза в неделю => 5мин * 52недели / 60 мин = 4,3 часа простоя в год без учета выходных, т.е. в итоге примерно 6 часов. Не такие уж и жесткие ограничения.
Что касается кластера, так я на нем и не настаиваю. У меня полностью отсутствует практический опыт работы с кластерными решениями, поэтому я не могу объективно преставлять себе их возможности по обеспечению отказоустойчивости. Такую информацию я как раз и хотел получить от Вас.
По поводу репликации. На каком уровне производить репликацию ? На уровне NTFS или на уровне баз данных или ??? У меня нет информации по функционированию Pervasive SQL в подобном режиме (а у Вас ?). Что делать с репликациями файловой помойки ? (Опять же какими средствами и насколько они совместимы с остальными задачами, необходимо ли учитывать это сразу или репликации можно настроить позже на произвольный сервер (например, наш старый сервер под Netware). Если мы настраиваем репликации, чтобы обеспечить изоляцию от логических ошибок, зачем нам нам общая дисковая система ?
Кроме того, обращаю ваше внимание, что неизвестно еще как сильно пострадает производительность в случае объединения всех задач на одной машине. У меня нет информации о том, как сильно падает производительность при использовании служб терминалов. Мое мнение, что двух машин здесь явно не хватает... Я не зря (или зря?) вынес серверы приложений в отдельные задачи...
- TeRminaToR
- Advanced member
- Сообщения: 105
- Зарегистрирован: 07 окт 2002, 20:07
- Откуда: Москва
- Контактная информация:
Еще несколько замечаний по поводу репликации. Нужна ли нам репликация? Pervasive SQL умеет делать "моментальные снимки" с определенных баз. Давайте введем резервирование именно по этим снимкам. Т.е. есть основное хранилище баз, с него по определенному алгоритму и с определенной интенсивностью делаются "слепки" которые складируются на резервном сервере, который, в свою очередь, в случае необходимости, может занять место основного сервера.
Пусть базы RS-Bank и BSSclient резервируются раз в час . Резервные базы не испытывают нагрузки пользователей, а значет могут хранится на чем-либо более дешевом чем SCSI Raid, например, на IDE Raid (какие еще есть варианты?). В случае логического сбоя на главном сервере у нас есть несколько вариантов:
1) Попытаться восстановить текущие базы специальными утилитами (butil и иже с ним)
2) Восстановить базы из последнего слепка (откат работы на 1 час будем считать неопределенно допустимым)
3) В случае аппаратного сбоя главного сервера, восстановить базы на резервном и включить его вместо основного.
4) Можно предусмотреть вариант, когда корзина с массивом информации просто переставляется на резервный сервер, тогда в случае логической целостности информации резервный сервер может занять место основного и использовать текущую версию баз. Это избавляет нас от необходимости резервировать какие-либо подсистемы главного сервера кроме дисковой (не так ли ) и соответственно приводит к его удешевлению.
Кроме этого, резервирование по "слепкам" избавляет от ошибок пользователей, например, неправильно проведенной проводки или еще что-то в этом духе.
Предоставляет ли репликация подобный сервис ? Конечно, откат проводки можно сделать средствами RS-bank и в этом случае вовсе не обязательно прибегать к резервной копии, НО...
Что делать, если происходит сбой репликации? Рассинхронизация баз? Возможна ли такая ситуация и как с ней бороться?
Как вам такой вариант? Я не в коей мере на нем не настаиваю, просто надо принять факт существования именно такого варианта и, возможно, его необходимости. Откат на час назад приемлем в общем только в исключительных ситуациях, но не в несут ли репликации более серьезные накладные расходы и большую вероятность появления ошибок? Обеспечат ли они большую отказоустойчивость в нашем случае?
Пусть базы RS-Bank и BSSclient резервируются раз в час . Резервные базы не испытывают нагрузки пользователей, а значет могут хранится на чем-либо более дешевом чем SCSI Raid, например, на IDE Raid (какие еще есть варианты?). В случае логического сбоя на главном сервере у нас есть несколько вариантов:
1) Попытаться восстановить текущие базы специальными утилитами (butil и иже с ним)
2) Восстановить базы из последнего слепка (откат работы на 1 час будем считать неопределенно допустимым)
3) В случае аппаратного сбоя главного сервера, восстановить базы на резервном и включить его вместо основного.
4) Можно предусмотреть вариант, когда корзина с массивом информации просто переставляется на резервный сервер, тогда в случае логической целостности информации резервный сервер может занять место основного и использовать текущую версию баз. Это избавляет нас от необходимости резервировать какие-либо подсистемы главного сервера кроме дисковой (не так ли ) и соответственно приводит к его удешевлению.
Кроме этого, резервирование по "слепкам" избавляет от ошибок пользователей, например, неправильно проведенной проводки или еще что-то в этом духе.
Предоставляет ли репликация подобный сервис ? Конечно, откат проводки можно сделать средствами RS-bank и в этом случае вовсе не обязательно прибегать к резервной копии, НО...
Что делать, если происходит сбой репликации? Рассинхронизация баз? Возможна ли такая ситуация и как с ней бороться?
Как вам такой вариант? Я не в коей мере на нем не настаиваю, просто надо принять факт существования именно такого варианта и, возможно, его необходимости. Откат на час назад приемлем в общем только в исключительных ситуациях, но не в несут ли репликации более серьезные накладные расходы и большую вероятность появления ошибок? Обеспечат ли они большую отказоустойчивость в нашем случае?
- TeRminaToR
- Advanced member
- Сообщения: 105
- Зарегистрирован: 07 окт 2002, 20:07
- Откуда: Москва
- Контактная информация:
Что касается платформы на которой все это реализуется, то никакой привязанности нет. Известно, что Pervasive SQL может работать на SUN. Кроме того, часть задач таких как файл сервер и сервер терминалов вообще на платформу не завязаны! Так что давайте не будем их исключать...
Что касается нашего бюджета, то 20000$ не предел. Руководство банка подходит к решению подобных задач так: надо - значит надо, но вот надо ли ?
По-моему, задачу я поставил достаточно четко, если какой-либо информации в постановке задачи не хватает, давайте сначала скорректируем именно ТЗ. А если для реализации поставленной задачи объективно понадобится 50000$ и мы сможем это доказать - это не проблема. Но не надо забывать, во-первых, о существующей сестеме на которой все работает более 5 лет и о системах конкурентов у которых тоже все работает. Надо найти оптимум в обеспечении надежности и цены... Уступки могут быть как с одной, так и с другой стороны.
В общем случае, предлагаю оптимизировать систему по такому критерию:
k = (Увеличение надежности / Увеличение стоимости) -> max
Например, увеличение надежности на 10% требует увеличения затрат на 5%, k=10/5=2 или увеличение надежности на 1% требует увеличения затрат на 3%, k=0,333. Следовательно первый вариант относительно приемлем, второй - нет. В общем случае ищем такой вариант, при котором k=max
Что касается нашего бюджета, то 20000$ не предел. Руководство банка подходит к решению подобных задач так: надо - значит надо, но вот надо ли ?
По-моему, задачу я поставил достаточно четко, если какой-либо информации в постановке задачи не хватает, давайте сначала скорректируем именно ТЗ. А если для реализации поставленной задачи объективно понадобится 50000$ и мы сможем это доказать - это не проблема. Но не надо забывать, во-первых, о существующей сестеме на которой все работает более 5 лет и о системах конкурентов у которых тоже все работает. Надо найти оптимум в обеспечении надежности и цены... Уступки могут быть как с одной, так и с другой стороны.
В общем случае, предлагаю оптимизировать систему по такому критерию:
k = (Увеличение надежности / Увеличение стоимости) -> max
Например, увеличение надежности на 10% требует увеличения затрат на 5%, k=10/5=2 или увеличение надежности на 1% требует увеличения затрат на 3%, k=0,333. Следовательно первый вариант относительно приемлем, второй - нет. В общем случае ищем такой вариант, при котором k=max
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
Terminator
Хорошая тема. Можно и я кину 5 копеек (не имею опыта работы в банках, правда, но имею опыт работы с нетолстыми БД (Oracle, IB, MySQL объемом до 2 Гб и до 100 пользователей ) ?
Попробуем абстрагироваться от деталей(комплектующие, ОС) и привести задачу к известным (как в анекдоте про математика и чайник;) ):
1. Файлпомойка.
2. Сервер, на котором работает БД операторов, обслуживающих клиентов
3. Сервер БД для аналитики
4. Терминальный сервер.
Так. Возникают следующие вопросы:
1. У Вас в качестве рабочих мест операторов используются терминалы или РС ? Если РС, то- терминальный сервер можно сразу отбросить - лучше довести до ума базу и комплектуху рабочих мест. Если терминалы - это другое дело. Опять-таки: что используется для их загрузки: бездисковая типа по DHCP/TFTP (как обычно в самопальных) или флэш(как в фирменных) с чем-то типа Windows CE ?
2. Объем БД ? Рост в месяц/год ? Ответы на эти вопросы важны, т.к. можно сразу прикинуть необходимые начальные конфигурации под сервера БД и их необходимую масштабируемость (запас по масштабируемости при текущем объеме и темпах роста нужно закладывать имхо не менее, чем на 5 лет).
Опять имхо: по опыту моей работы сервера БД под задачи сбора информации и "тяжелой" аналитики лучше разносить физически на разные машины.
3. Опять-таки по терминалам, если они есть: Что на них выполняется ? Только клиенты БД или Word/Excel/etc. ? Тоже важно для определения конфигурации терминального сервера.
4. Отказоустойчивость: все имхо, т.к. опыта в данной части нет.
Нужно добиваться в данном случае не отказоустойчивости как таковой (24/7/365), а гарантированной работоспособности системы в течение банковского дня, т.е. времени, когда производятся активные операции (Сбор данных, аналитика, отчетность).
В этом случае (приведенном, а не общем) затраты на избыточное оборудование, необходимое для обеспечения отказоустойчивости, существенно ниже.
Ну, по файловой помойке, думаю, лучше спросить специалистов из Тринити: имхо, Вам нужен массив NAS-серверов, поддерживающих RAID не менее 10 (имею в виду страйп зеркал), можно в крайнем случае даже на IDE-дисках (хотя тут стоит вопрос хот-свапа). Почему именно массив(не менее двух) ? Обычно, такие (нетипизированные, не подходящие для внесения/учета в общей БД) данные, которые хранятся на файлпомойках, не очень критичны к 5-10 минутным простоям. Но, имхо, не стоит подвергать всю файлпомойку разом угрозе такого останова. Пусть лучше пара операторов 5 минут подождет, или один отдел, но не все разом (в худшем случае, конечно). Плюс к массиву 1 резервный сервер NAS для переброса инфы и нагрузки на него в самом плохом случае.
Все вышесказанное имхо.
Если сочтете информацию выше полезной для себя, и ответите на вышеприведенные вопросы - попробую развить тему дальше (детализировать).
Хорошая тема. Можно и я кину 5 копеек (не имею опыта работы в банках, правда, но имею опыт работы с нетолстыми БД (Oracle, IB, MySQL объемом до 2 Гб и до 100 пользователей ) ?
Попробуем абстрагироваться от деталей(комплектующие, ОС) и привести задачу к известным (как в анекдоте про математика и чайник;) ):
1. Файлпомойка.
2. Сервер, на котором работает БД операторов, обслуживающих клиентов
3. Сервер БД для аналитики
4. Терминальный сервер.
Так. Возникают следующие вопросы:
1. У Вас в качестве рабочих мест операторов используются терминалы или РС ? Если РС, то- терминальный сервер можно сразу отбросить - лучше довести до ума базу и комплектуху рабочих мест. Если терминалы - это другое дело. Опять-таки: что используется для их загрузки: бездисковая типа по DHCP/TFTP (как обычно в самопальных) или флэш(как в фирменных) с чем-то типа Windows CE ?
2. Объем БД ? Рост в месяц/год ? Ответы на эти вопросы важны, т.к. можно сразу прикинуть необходимые начальные конфигурации под сервера БД и их необходимую масштабируемость (запас по масштабируемости при текущем объеме и темпах роста нужно закладывать имхо не менее, чем на 5 лет).
Опять имхо: по опыту моей работы сервера БД под задачи сбора информации и "тяжелой" аналитики лучше разносить физически на разные машины.
3. Опять-таки по терминалам, если они есть: Что на них выполняется ? Только клиенты БД или Word/Excel/etc. ? Тоже важно для определения конфигурации терминального сервера.
4. Отказоустойчивость: все имхо, т.к. опыта в данной части нет.
Нужно добиваться в данном случае не отказоустойчивости как таковой (24/7/365), а гарантированной работоспособности системы в течение банковского дня, т.е. времени, когда производятся активные операции (Сбор данных, аналитика, отчетность).
В этом случае (приведенном, а не общем) затраты на избыточное оборудование, необходимое для обеспечения отказоустойчивости, существенно ниже.
Ну, по файловой помойке, думаю, лучше спросить специалистов из Тринити: имхо, Вам нужен массив NAS-серверов, поддерживающих RAID не менее 10 (имею в виду страйп зеркал), можно в крайнем случае даже на IDE-дисках (хотя тут стоит вопрос хот-свапа). Почему именно массив(не менее двух) ? Обычно, такие (нетипизированные, не подходящие для внесения/учета в общей БД) данные, которые хранятся на файлпомойках, не очень критичны к 5-10 минутным простоям. Но, имхо, не стоит подвергать всю файлпомойку разом угрозе такого останова. Пусть лучше пара операторов 5 минут подождет, или один отдел, но не все разом (в худшем случае, конечно). Плюс к массиву 1 резервный сервер NAS для переброса инфы и нагрузки на него в самом плохом случае.
Все вышесказанное имхо.
Если сочтете информацию выше полезной для себя, и ответите на вышеприведенные вопросы - попробую развить тему дальше (детализировать).
- TeRminaToR
- Advanced member
- Сообщения: 105
- Зарегистрирован: 07 окт 2002, 20:07
- Откуда: Москва
- Контактная информация:
У нас на рабочих местах стоят достаточно хорошие машины, в среднем PIII850/256Mb, у привелигированных пользователей P4 2.2 / 256DDR, сетевушки Intel PRO 100+ соединены через 2 свича 3COM 3300.1. У Вас в качестве рабочих мест операторов используются терминалы или РС ? Если РС, то- терминальный сервер можно сразу отбросить - лучше довести до ума базу и комплектуху рабочих мест. Если терминалы - это другое дело. Опять-таки: что используется для их загрузки: бездисковая типа по DHCP/TFTP (как обычно в самопальных) или флэш(как в фирменных) с чем-то типа Windows CE ?
Терминальный доступ используется сейчас лишь для 10 пользователей, но идея нам понравилась, и, с целью обеспечения конфиденциальности, мы планируем перевести по возможности всех пользователей на терминальный доступ. Проблема в неработоспособности некоторых программ через терминал и большой нагрузке на сервер, но при наших объемах, я думаю, проблема разрешима.
Объем БД учитывался в описании нагрузки на файл-сервер. Если интересует конкретно, то текущая база RS-bank около 0.5Гб, текущая база BSclient 200Мб, и еще около 1Гб специализированной динамически изменяемой информации. Остальное архивы, дистрибутивы и прочая помойка.Объем БД ? Рост в месяц/год ? Ответы на эти вопросы важны, т.к. можно сразу прикинуть необходимые начальные конфигурации под сервера БД и их необходимую масштабируемость (запас по масштабируемости при текущем объеме и темпах роста нужно закладывать имхо не менее, чем на 5 лет).
Опять имхо: по опыту моей работы сервера БД под задачи сбора информации и "тяжелой" аналитики лучше разносить физически на разные машины.
Необходимое оборудование под это дело определить достаточно просто исходя из существующих объемов накопителей. 9Гб - уже устарели, 36Гб - много => 18Гиг x2 (для резервирования). Вот и вся матемитика... Но это выбирем потом, после того как решим как вообще хранить и бекапить информацию... Может проще будет один большой RAID массив иметь, а может лучше много но по-меньше... Но все это потом. Давайте решим сначало как это вообще лучше организовать с точки зрения архитектуры...
На терминалах выполняется все! И клиенты БД, и Word и Excel и еще много всякого софта. Я даже планирую сделать выделенный терминал сервер для доступа в интернет, чтобы локализовать весь внешний траффик...3. Опять-таки по терминалам, если они есть: Что на них выполняется ? Только клиенты БД или Word/Excel/etc. ? Тоже важно для определения конфигурации терминального сервера.
Банк работает с деньгами практически круглосуточно. Результаты 4-го рейса приходят в 8 часов, программисты уходят в 6. Что если сервер откажет ? А что если они в 12 ночи решат деньги отправить, а сервер не работает ? Так что закладываться на простои по ночам нельзя.4. Отказоустойчивость: все имхо, т.к. опыта в данной части нет.
Нужно добиваться в данном случае не отказоустойчивости как таковой (24/7/365), а гарантированной работоспособности системы в течение банковского дня, т.е. времени, когда производятся активные операции (Сбор данных, аналитика, отчетность).
Не думаю, что нам вообще нужны NAS'ы... Дорого, да и не работаем мы с таким большимы объемами информации где они себя оправдывают... RAID стойка может быть, а вообще пусть действительно специалисты тринити предлагают как надо сделать.у, по файловой помойке, думаю, лучше спросить специалистов из Тринити: имхо, Вам нужен массив NAS-серверов, поддерживающих RAID не менее 10 (имею в виду страйп зеркал), можно в крайнем случае даже на IDE-дисках (хотя тут стоит вопрос хот-свапа). Почему именно массив(не менее двух) ? Обычно, такие (нетипизированные, не подходящие для внесения/учета в общей БД) данные, которые хранятся на файлпомойках, не очень критичны к 5-10 минутным простоям. Но, имхо, не стоит подвергать всю файлпомойку разом угрозе такого останова. Пусть лучше пара операторов 5 минут подождет, или один отдел, но не все разом (в худшем случае, конечно). Плюс к массиву 1 резервный сервер NAS для переброса инфы и нагрузки на него в самом плохом случае.
- TeRminaToR
- Advanced member
- Сообщения: 105
- Зарегистрирован: 07 окт 2002, 20:07
- Откуда: Москва
- Контактная информация:
Ребята, а возможно ли сотворить такое:
Вся работа производится на главном очень хорошем сервере с двумя быстрыми дисками в зеркале. По определенному алгоритму один из дисков зеркала выводится из массива и монтируется другим (сервером бекапа) как отдельная файловая система. Вся работа продолжается без остановки на основном сервере но уже без резервирования (а может можно 3 диска в зеркало поставить?), а в это время резервный сервер, подмонтировав диск из зеркала, бекапит с него информацию на свои носители не мешая основному серверу. После сохранения информации, диск обратно отдается в раид массив и ребилдится.... После чего бекап повторяется...
Если так невозможно или неоптимально, можно сделать очень быстрый дисковый массив на главном сервере, опять же по определенному алгоритму приостанавливать сервисы для пользователей и бекапить информацию (как я уже говорил, в динамике примерно 2Гб). Сколько времени займет бекап 2Гб ? 1-2 минуты простоя в час пользователям могут быть даже полезны, тем более, что простои будут связаны лишь с изменением информации, а для чтения она будет доступна постоянно...
Вся работа производится на главном очень хорошем сервере с двумя быстрыми дисками в зеркале. По определенному алгоритму один из дисков зеркала выводится из массива и монтируется другим (сервером бекапа) как отдельная файловая система. Вся работа продолжается без остановки на основном сервере но уже без резервирования (а может можно 3 диска в зеркало поставить?), а в это время резервный сервер, подмонтировав диск из зеркала, бекапит с него информацию на свои носители не мешая основному серверу. После сохранения информации, диск обратно отдается в раид массив и ребилдится.... После чего бекап повторяется...
Если так невозможно или неоптимально, можно сделать очень быстрый дисковый массив на главном сервере, опять же по определенному алгоритму приостанавливать сервисы для пользователей и бекапить информацию (как я уже говорил, в динамике примерно 2Гб). Сколько времени займет бекап 2Гб ? 1-2 минуты простоя в час пользователям могут быть даже полезны, тем более, что простои будут связаны лишь с изменением информации, а для чтения она будет доступна постоянно...
- gs
- Сотрудник Тринити
- Сообщения: 16650
- Зарегистрирован: 23 авг 2002, 17:34
- Откуда: Москва
- Контактная информация:
Что касается разбирания и ребилда рэйда - забудьте и не пытайтесь!!!!!!!!!!!!!!!!!!! Что-то типа этого (не точно так, но логически вроде того) умеют делать тяжелые дисковые системы ценой в десятки-сотни тысяч. Постоянное повторение таких операций на обычном контроллере со стопроцентной вероятностью приведет к развалу системы - это просто вопрос времени.
ЕСЛИ РЭЙД РАБОТАЕТ, НЕ ТРОГАЙТЕ ЕГО!!!
Что касается второго. Если Вы можете принудительно приостанавливать операции записи, то проблем вообще нет - любой бэкапный софт с этим справится. Хотя, имхо, это трудно организовать административно.
Лучше пойти стандартным путем - бэкапный софт с агентами для баз данных и опен файл опшен для обычных файлов. Ничего даже останавливать не придется.
А если Вы будете бэкапиться очень часто, то понадобится либо очень быстрый стример (типа LTO, но это порядка 5k$) или двухступенчатый бэкап - сначала на диск (несколько сессий, а уже оттуда на какой-нибудь стример).
ЕСЛИ РЭЙД РАБОТАЕТ, НЕ ТРОГАЙТЕ ЕГО!!!
Что касается второго. Если Вы можете принудительно приостанавливать операции записи, то проблем вообще нет - любой бэкапный софт с этим справится. Хотя, имхо, это трудно организовать административно.
Лучше пойти стандартным путем - бэкапный софт с агентами для баз данных и опен файл опшен для обычных файлов. Ничего даже останавливать не придется.
А если Вы будете бэкапиться очень часто, то понадобится либо очень быстрый стример (типа LTO, но это порядка 5k$) или двухступенчатый бэкап - сначала на диск (несколько сессий, а уже оттуда на какой-нибудь стример).
- TeRminaToR
- Advanced member
- Сообщения: 105
- Зарегистрирован: 07 окт 2002, 20:07
- Откуда: Москва
- Контактная информация:
Можно по-подробнее об этой возможности ? Что за бекапный софт, совместим ли он с нашим ПО ? Сейчас мы просто копируем, а потом архивируем необходимые каталоги и все...Лучше пойти стандартным путем - бэкапный софт с агентами для баз данных и опен файл опшен для обычных файлов. Ничего даже останавливать не придется.
Нет, стример нам не нужен, DVD-R может быть, а стример точно не нужен... Ведь нам необходимо бекапит 2Гб цикличеки каждый час, а на потом будет оставаться только 2Гб за каждый день в течение месяца. Из этих 60ГБ на постоянное хранение уйдет 3-4Гб, а это как раз DVD-R дискА если Вы будете бэкапиться очень часто, то понадобится либо очень быстрый стример (типа LTO, но это порядка 5k$) или двухступенчатый бэкап - сначала на диск (несколько сессий, а уже оттуда на какой-нибудь стример).
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
TeRminaToR
Извините, но, имхо, не стоит возводить терминальный доступ в ранг самоцели. Вы сами заметили, что это приводит к значительной нагрузке на терминальный сервер. Мне приходилось проектировать для клиента подобные вещи, и у меня вышел примерно 1 сервер калибра IBM x232 на 25 клиентов. С количеством клиентов свыше 35 на один сервер уже начинались тормоза. Т.е. получается, что вместо того, чтобы настроить софт на имеющихся РС, приобретаем два сервера. Так ? Не спорю - управлять и обслуживать терминалку проще.
И потом - что значит в данном контексте конфиденциальность ? Если у Вас на всех РС W2K, тогда все решается правами и доменными политиками. Если 9х - сочувствую... Тогда действительно лучше терминалка.
Не понял... Наличие SQL-сервера исключает необходимость файлпомойки под БД. С другой стороны, эти вещи не стоит совмещать(SQL-сервер и файл-сервер) - разные задачи, и, как следствие, разные комплектации серверов.
Про накопители я умолчу - замечу лишь, что в большинстве рекомендованных и поставленных мной (я не отношусь к Тринити) серверов под SQL как раз применялись 36 Гб винты, 18 Гб я обычно ставлю в зеркало под ОС и ее дела. 9 Гб для U160/320 я не видел, а эти интерфейсы сейчас являются стандартными (винты на 9 чаще всего встречались в конфигурациях с Fast/Ultra Wide SCSI).
Что касается RAID: опять же, определяться нужно, имхо, сначала с базой SQL:
Не знаю, как Pervasive, но под Oracle мы старались разнести сегменты данных на один винт, а индексы/откат/журнал и пр. на другой - тем самым достигалось максимальная производительность за счет распараллеливания запросов к винтам/массивам. Потому я и упомянул выше о разнице в конфигурации сервера под SQL и файл-сервера - для второго данные для лучшей управляемости, имхо, лучше иметь в едином массиве (хотя это и не единственное отличие). Опять-таки, характер работы SQL с винтами - чтение/запись "вразброс" относительно малыми блоками, файл-сервера - характерно как чтение малыми блоками, так и массированное последовательное чтение/запись, кроме того, нагрузка на файл сервер имеет характерные пики (начало/обед/конец рабочего дня). SQL таких пиков не имеет (исключая аналитику, конечно).
Это что касается винтов. Процессоры - для файл-сервера их число и тактовая частота не столь важны, сколь производительность дисковой подсистемы. Для SQL - почти наоборот (дисковая, правда, тоже важна - но не столь важен ее объем, как для файлового). Память - для SQL (OLTP)рекомендуется иметь примерно 50% от планируемого объема БД (на момент следующего апгрейда). Для файлового - зачастую 256-512 Мб за глаза при Ваших объемах.
Что касается решений для бэкапа: имхо, то, что Вы предложили в своем последнем посте, для аппаратного внутреннего RAID - ситуация катастрофичная (выпадение винта из массива). Добровольно такое делать не стоит.
Дисков в зеркало можно ставить сколько угодно.
Есть куда проще : инкрементный бэкап на стример (объемы будут невелики, да и сколько-нибудь заметных ресурсов это дело не отнимет) либо он-лайн репликация на аналитический сервер и бэкап оттуда(тоже-на стример, имхо, пока ничего надежнее не придумано) - кстати, еще лучше.
Все вышесказанное, естественно, имхо.
Нда.. понаписал...
Если Вам мое мнение не интересно - сообщите в Вашем следующем посте. Больше не буду
Извините, но, имхо, не стоит возводить терминальный доступ в ранг самоцели. Вы сами заметили, что это приводит к значительной нагрузке на терминальный сервер. Мне приходилось проектировать для клиента подобные вещи, и у меня вышел примерно 1 сервер калибра IBM x232 на 25 клиентов. С количеством клиентов свыше 35 на один сервер уже начинались тормоза. Т.е. получается, что вместо того, чтобы настроить софт на имеющихся РС, приобретаем два сервера. Так ? Не спорю - управлять и обслуживать терминалку проще.
И потом - что значит в данном контексте конфиденциальность ? Если у Вас на всех РС W2K, тогда все решается правами и доменными политиками. Если 9х - сочувствую... Тогда действительно лучше терминалка.
Объем БД учитывался в описании нагрузки на файл-сервер.
Не понял... Наличие SQL-сервера исключает необходимость файлпомойки под БД. С другой стороны, эти вещи не стоит совмещать(SQL-сервер и файл-сервер) - разные задачи, и, как следствие, разные комплектации серверов.
Опять не понял. А зачем тогда спрашивали ?Необходимое оборудование под это дело определить достаточно просто
Про накопители я умолчу - замечу лишь, что в большинстве рекомендованных и поставленных мной (я не отношусь к Тринити) серверов под SQL как раз применялись 36 Гб винты, 18 Гб я обычно ставлю в зеркало под ОС и ее дела. 9 Гб для U160/320 я не видел, а эти интерфейсы сейчас являются стандартными (винты на 9 чаще всего встречались в конфигурациях с Fast/Ultra Wide SCSI).
Что касается RAID: опять же, определяться нужно, имхо, сначала с базой SQL:
Не знаю, как Pervasive, но под Oracle мы старались разнести сегменты данных на один винт, а индексы/откат/журнал и пр. на другой - тем самым достигалось максимальная производительность за счет распараллеливания запросов к винтам/массивам. Потому я и упомянул выше о разнице в конфигурации сервера под SQL и файл-сервера - для второго данные для лучшей управляемости, имхо, лучше иметь в едином массиве (хотя это и не единственное отличие). Опять-таки, характер работы SQL с винтами - чтение/запись "вразброс" относительно малыми блоками, файл-сервера - характерно как чтение малыми блоками, так и массированное последовательное чтение/запись, кроме того, нагрузка на файл сервер имеет характерные пики (начало/обед/конец рабочего дня). SQL таких пиков не имеет (исключая аналитику, конечно).
Это что касается винтов. Процессоры - для файл-сервера их число и тактовая частота не столь важны, сколь производительность дисковой подсистемы. Для SQL - почти наоборот (дисковая, правда, тоже важна - но не столь важен ее объем, как для файлового). Память - для SQL (OLTP)рекомендуется иметь примерно 50% от планируемого объема БД (на момент следующего апгрейда). Для файлового - зачастую 256-512 Мб за глаза при Ваших объемах.
Хм. Ну, тогда, если позволяют деньги, необходим Failover Cluster для каждой из основных задач (т.е. буквально все должно быть сдублировано, как минимум) - в идеальном случае, конечно же. На практике он может понадобиться только для того сервера БД, который будет использоваться для сбора данных. Аналитика и отчетность - вещи, в реальном времени не настолько часто происходящие, чтобы заморачиваться 5-10 минутным простоем в худшем случае.Банк работает с деньгами практически круглосуточно.
Если исключить объем БД из объемов, указанных для файл-сервера, то да, не нужны. Хотя - как решение для файл-серверов, имхо, неплохи - и не так уж и дороги, кстати.Не думаю, что нам вообще нужны NAS'ы
Что касается решений для бэкапа: имхо, то, что Вы предложили в своем последнем посте, для аппаратного внутреннего RAID - ситуация катастрофичная (выпадение винта из массива). Добровольно такое делать не стоит.
Дисков в зеркало можно ставить сколько угодно.
Есть куда проще : инкрементный бэкап на стример (объемы будут невелики, да и сколько-нибудь заметных ресурсов это дело не отнимет) либо он-лайн репликация на аналитический сервер и бэкап оттуда(тоже-на стример, имхо, пока ничего надежнее не придумано) - кстати, еще лучше.
Все вышесказанное, естественно, имхо.
Нда.. понаписал...
Если Вам мое мнение не интересно - сообщите в Вашем следующем посте. Больше не буду
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 4 гостя