Статья, безусловно, интересная и полезная как пример использования возможностей SharePoint.
Фактически автор реализовал функционал дорогих ITIL продуктов на базе SharePoint. Жалко не приведены скриншоты.
Но, я все таки считаю, что данные и логику всего этого хозяйства правильнее организовать в виде отдельного приложения на основе SQL Server, а SharePoint использовать как Front-End. Правда, здесь уже нужно будет привлекать разработчиков.
Не могли бы вы дать ссылку на ваш интернет сайт на базе SharePoint. Укромно так. :) Дабы избежать хабраэффекта.
Жаль что многие не понимают, что первично — это решаемые задачи, а инструменты это вторично. Linux, Windows — какая разница. Есть определенные задачи которые нужно решить в соответствии с заданными условиями и ограничениями. То что в данном конкретном случае больше подходит — то и используем.
Признаюсь, с DRBD я не работал. Но пробежался сейчас по Интернет дабы получить общее представление.
Поправьте меня, если я ошибаюсь.
Есть два момента (точнее полтора) по которым решение CTDB лучше. Точнее, не так. Не лучше. Это просто решения под разные задачи.
1. с CTDB Samba на узлах работает в режиме Active — Active с балансировкой нагрузки, в то время как с HeartBeat Active — Passive. Т.е. вторая самба просто простаивает и берет на себя управления только в случае сбоя. Не исключаю, что вторую и последующие Samba можно сделать активными при использовании поверх DRBD кластерной ФС, но уже точно они не будут обслуживать те же самые файлы.
Без механизма совместного использования TDB, который обеспечивает CTDB, одновременная работа Samba на разных узлах с одним и тем же набором файлов невозможна.
2. При классическом использовании DRBD работает как Primary -> Slave. Записывать данные можно только на Primary. Затем все копируется на подчиненные узлы. Еще одна причина, о чем говорилось в пункте 1, к тому, чтобы вторая и последующие самба не могли быть активными.
Кроме того, подозреваю что режим Primary -> Slave создает неплохую нагрузку на сеть, особенно с количеством узлов больше 2-х. А распределения нагрузки никакой нет.
Последние версии DRBD поддерживают кластерные файловые системы. Теперь можно писать одновременно на двух узлах. Тем не менее, мне кажется что схема при количестве узлов больше 2-х с кластерной файловой системой поверх будет сильно не оптимальной, Samba также не будет работать в режиме Active — Active, т.к. размещение TDB файлов на кластерной ФС приведет к тормозам.
Я так думаю, DRBD + HeartBeat — это сугубо отказоустойчивое Low End решение что называется с минимальными средствами. В то время как CTDB более масштабируемое решение.
Я бы вам рекомендовал попробовать CTDB + DRBD + кластерная ФС. Может быть получится неплохо с небольшим количеством узлов.
Сухо? Ну так и я не Евгений Петросян, и Хабр не передача Аншлаг. :)
А вообще, вы правы, материалы этой статьи будут использованы в написании технической документации к одному из проектов. А там особых вольностей себе не позволишь, поэтому старался писать как можно строже.
Вы не внимательно читали. На heartbeat теоретичесик можно и, судя по всему, пробовали. Но что вы будете делать с TDB базами Samba? Как заставить их работать в кластере, как при обрашении к одному файлу через 2 узла кластера реализовать блокировки?
Именно это (работа с TDB в кластере) основная проблема.
Фактически автор реализовал функционал дорогих ITIL продуктов на базе SharePoint. Жалко не приведены скриншоты.
Но, я все таки считаю, что данные и логику всего этого хозяйства правильнее организовать в виде отдельного приложения на основе SQL Server, а SharePoint использовать как Front-End. Правда, здесь уже нужно будет привлекать разработчиков.
Не могли бы вы дать ссылку на ваш интернет сайт на базе SharePoint. Укромно так. :) Дабы избежать хабраэффекта.
Не совсем понял по поводу партнеров. Они же получают продукты в рамках партнерской подписки. Причем тут SA? Когда же ждать?
Жаль что многие не понимают, что первично — это решаемые задачи, а инструменты это вторично. Linux, Windows — какая разница. Есть определенные задачи которые нужно решить в соответствии с заданными условиями и ограничениями. То что в данном конкретном случае больше подходит — то и используем.
Все зависит от задач.
Поправьте меня, если я ошибаюсь.
Есть два момента (точнее полтора) по которым решение CTDB лучше. Точнее, не так. Не лучше. Это просто решения под разные задачи.
1. с CTDB Samba на узлах работает в режиме Active — Active с балансировкой нагрузки, в то время как с HeartBeat Active — Passive. Т.е. вторая самба просто простаивает и берет на себя управления только в случае сбоя. Не исключаю, что вторую и последующие Samba можно сделать активными при использовании поверх DRBD кластерной ФС, но уже точно они не будут обслуживать те же самые файлы.
Без механизма совместного использования TDB, который обеспечивает CTDB, одновременная работа Samba на разных узлах с одним и тем же набором файлов невозможна.
2. При классическом использовании DRBD работает как Primary -> Slave. Записывать данные можно только на Primary. Затем все копируется на подчиненные узлы. Еще одна причина, о чем говорилось в пункте 1, к тому, чтобы вторая и последующие самба не могли быть активными.
Кроме того, подозреваю что режим Primary -> Slave создает неплохую нагрузку на сеть, особенно с количеством узлов больше 2-х. А распределения нагрузки никакой нет.
Последние версии DRBD поддерживают кластерные файловые системы. Теперь можно писать одновременно на двух узлах. Тем не менее, мне кажется что схема при количестве узлов больше 2-х с кластерной файловой системой поверх будет сильно не оптимальной, Samba также не будет работать в режиме Active — Active, т.к. размещение TDB файлов на кластерной ФС приведет к тормозам.
Я так думаю, DRBD + HeartBeat — это сугубо отказоустойчивое Low End решение что называется с минимальными средствами. В то время как CTDB более масштабируемое решение.
Я бы вам рекомендовал попробовать CTDB + DRBD + кластерная ФС. Может быть получится неплохо с небольшим количеством узлов.
А вообще, вы правы, материалы этой статьи будут использованы в написании технической документации к одному из проектов. А там особых вольностей себе не позволишь, поэтому старался писать как можно строже.
На 4-й тоже все работает
Именно это (работа с TDB в кластере) основная проблема.
С 2008-м сервером работать будет. Про расширенные права, признаюсь, не знаю, т.к. не было необходимости пока разбираться.
Длинновато конечно получилось, согласен. Наверное, имело смысл разбить на 2 части.