Привет! Дискламбер - трава у нас бывает разная, кому не нравится - не нюхайте.
Некоторые осведомленные люди (типа Джима Старки) в своих мемуарах писали, что interbase был изначально придуман как сервер для кластеров. Так как у некоторых товарищей до сих пор существуют или абсолютно невнятные представления о том, что такое кластеры и с чем их едят, или отсутствуют такие представления вообще, я и затеял эту ветку. Я не буду тут сыпать определениями (кому надо - погуглит), а просто расскажу о том, что такое кластеры, с чем их едят и какая от этого польза для БД. Итак, кластер - это группа компьютеров, которые работают совместно над какой-нибудь общей задачей. В некоторых случаях, кластером могут называть группу кластеров. Звучит немного рекурсивно, но это так. Есть много типов кластеров, но нас интересуют только три: 1) отказоустойчивые кластеры (High-availability clusters, HAC) 2) кластеры с балансировкой нагрузки (Load balancing clusters, LBC) 3) высокопроизводительные кластеры (High-performance clusters, HPC) (кому хочется подробностей - http://ru.wikipedia.org/wiki/Кластер а оттуда на кластер в виде группы компьютеров). Как обычно, нам бы таблетку от жадности, да побольше: все хотят и отказоустойчивый, и чтобы нагрузку сам распределял и работал быстро-быстро, быстрее чем Крэй (есть такие миленькие машинки с 5-6к процессоров, общей памятью в пару терабайт и неразглашаемой стоимостью). При этом, все, кто краем уха слышал что-то о кластерах, считает, что это решение всех проблем - "Давайте водрузим нашу прогу на кластер и оно за нас работать будет быстрее". Должен вас очень сильно огорчить - это далеко не так. И я даже не буду говорить о том, что доставить, настроить и обслуживать такого монстра ой как тяжко. SUN Microsystems вам доставит свой суперкомпьютер о 72 головах (каждая голова может быть 6-ти ядерной и более) в любую точку мира в течение месяца. И даже настроит - "бесплатно". Но вы все равно не купите :) Если кратко, то отказоустойчивый кластер является таковым за счет того, что "в случае чего" в строй вступают запасные узлы. Но при этом чудес не бывает - если узел чего-то там насчитал клиенту, но не успел отдать и упал - то клиент ничего не получит. Но если обратится еще раз - то все будет "клева". Сами попробуйте ответить, подходит ли вам это при работе с БД. Да, на всех машинах-узлах файл БД как буд-то бы один и тот же - специальный драйвер ФС делает всю работу по реальной записи файла прозрачной для приложения. Если сказать кратко - то это как зеркальный RAID. Только если в RAID не практикуется делать 1000 дисков в зеркале, то тут вполне себе возможно, все зависит от потребностей задачи. На основе модели, которая описана выше, не очень сложно представить себе, как работает кластер с балансировкой нагрузки - так как все узлы являются "зеркалами" друг друга, то можно Васе отдать на растерзание узел А, а Маше - узел Б и все будут довольны (ну кроме менеджера кластера, которому придется это все дело синхронизировать, лочить и заниматься всякими остальными извращениями). Говорят, что некоторые БД умеют делать такие извращения. Только чудес, как я уже говорил, не бывает. Представляете себе, что будет, если 2 ноды "упадут" в то время как пользователи интенсивно меняют данные? Веселуха разбираться в той каше, которая получится, будет еще та. А бэкапы, как известно, это удел трУсов. Бугага (у Коваленко другой бугага, поэтому его копирайты не ставлю). Третий тип кластеров к БД вообще никакого отношения не имеет. Это числодробилки. Вы забыли свой 18 символьный пароль? Тогда вам сюда. Хотите умножить матрицы 10000х10000 между собой? Пожалста, резервируйте время - где-то была инфа, что стоит около 10 центов час. Одного процессора. При покупке от недели и больше - скидки. Знакомый физик ездил в Швейцарию считать осаждение чего-то там (вроде атомов металлов) на различные поверхности. Считали взаимодействие 10 миллионов атомов или что-то около того. Крей пожужжал немного и выплюнул им пару двд данных - они их потом чуть ли не два года изучали. Более того, для этих числодробилок и проги надо писать соответственно - с учетом MPI API. Есть конечно альтернатива "классическому" HPC - MOSIX (http://www.mosix.org/) Для академических нужд бесплатно, для коммерческого использования что-то около 1к баксов на 10 узлов - копейки по сути дела. Представляет из себя патч для Линуха (виндузятники багровеют от зависти, я знаю сколько стоит дата-центр у мелкомягких), который позволяет 10-20-100 компов или кластеров (да-да, рекурсия) превратить как бы в один суперкомпьютер - у которого много процессоров. Вру. С точки зрения приложения это даже не важно много или один - многие программы запускаются нативно и ничего не замечают - это проблемы менеджера кластера, как выделить память и процессорное время задаче. Как только я познакомился с MOSIX тут же загорелся идеей. Потом понял, что все же есть подвох. Общей памяти нету. (Понятно почему классик держит все локи в файле? ;-) ) Если прога использует удаленные сокеты - то она не мигрируется. Треды на разные машины не раскидываются. Ну и куча прочих ограничений. Т.е. в бочке меда есть пару ложек дегтя. Что, думаете все, вешалка и надо завернуться в белую простынь? Не дождетесь. А вот что можно сделать в плане применения к БД, я постараюсь рассказать чуть позже - если общественность выразит свое мнение по поводу всего вышенаписанного и скажет, для чего им все-таки нужен кластер - чтобы не падало, быстрее работало или все вместе? -- Best regards, Sergey mailto:[EMAIL PROTECTED]
