Нужны советы и рекомендации по выбору аппаратного/программного обеспечения и схемы для организации работы комплексной системы по автоматизации предприятия. Система предсталяет собой клиент-серверное приложение работающее через браузер. На стороне сервера — фреймворк на J2EE и СУБД Postgresql. Ссылку на продукт давать не буду, посчитают рекламой.Сами разработчики рекомендуют следующее -2 сервера (один под БД, другой под продакшн приложение).Приблизительная конфигурация каждого сервера - 1 процессор (4-ядра, например 1 x 4-Core-Xeon ), 4 Гб оперативной памяти (лучше 2 планки по 2 Гб, или 1 планка 4 Гб), жесткие диски - raid (желательно sas) с выделенной кэш-памятью, суммарно на 72 Гб (c расчетом, что бэкапы будут переносится на другую машину). В качестве ОС рекомендуют Centos.
С учетом высокой важности этого приложения для работы нашей организации хотелось бы обеспечить максимальную надежность и управляемость приложения. Поэтому предполагается использование виртуализации и создание кластера высокой доступности. До сего дня я не работал с такими технологиями(за исключением KVM на одном сервере). Рассматриваются только opensource-решения. Материалов в данном направлении много, но выбрать самостоятельно что-нибудь не имея опыта работы довольно сложно. Из того, что нашел в Интернете, больше всего склоняюсь к решению http://www.opennet.me/tips/info/2514.shtml. То есть по сути два физических идентичных сервера, на каждом 2 VPS – сервер приложений и сервер баз данных. Физические сервера объединены в кластер. Если один выходит из строя, автоматически вся работа переключается на второй.
Необходимо выбрать:
1. Операционную систему (хостовую и гостевую)
2. Систему виртуализации(пока склоняюсь к OpenVZ)
3. Кластерную реализацию (пока склоняюсь к Heartbeat + DRBD)
> Нужны советы и рекомендации по выбору аппаратного/программного обеспечения и схемы для
> организации работы комплексной системы по автоматизации предприятия.Вам не приходило в голову задать этот вопрос разработчикам?
>4 Гб оперативной памяти (лучше 2 планки по 2 Гб, или 1 планка 4 Гб)
Вы очень мужественный человек, если с такими знаниями беретесь за такую задачу...
>То есть по сути два физических идентичных сервера, на каждом 2 VPS – сервер приложений и сервер баз данных.
То есть после того как вам разработчики порекомендовали разнести сервер баз данных и сервер приложений на две разные физические машины- вы тут же решили их объеденить. Да ужжжжж.....
Кстати если разработчики рекомендовали для базы данных и сервера приложений по 4 ядра и 4 гига- это значит, что если ввы будите засовывать их на одну машину- вам надо будет иметь на этой машине 8 ядер и 8 гигабайт памяти.
Виртуализация- не вытаскивает ресурсы компа "из воздуха". Если ваша система ТРЕБУЕТ под себя 4 гига оперативки (очень скромная система кстати) то не стоит надеятся что присоседив рядом вторую такуюже - вы получите такую же адекватную производительность на обеих системах. Напротив, они станут ОБЕ работать в два раза ХУЖЕ.Я бы сделал иначе - отдельно кластер высокой доступности из постргесса средствами постгресса (2 или 3 физически разных машины).
отдельно кластер из двух, физически разных машин для серверов приложений.
Итого 4 или 5 физических серверов на всю систему.
Виртуализация в данном случае - имеет смысл искючительно ради засовывания серверов в контенер, который потом можно будет легко брать и переносить между серверами (1 физический сервер- 1 виртуальная машина).Кстати вам туда надо будет еще и тестовую среду куда-нить засунуть... вот ее-то, и можно будет засунуть во второй контейнер.
>[оверквотинг удален]
> два раза ХУЖЕ.
> Я бы сделал иначе - отдельно кластер высокой доступности из постргесса средствами
> постгресса (2 или 3 физически разных машины).
> отдельно кластер из двух, физически разных машин для серверов приложений.
> Итого 4 или 5 физических серверов на всю систему.
> Виртуализация в данном случае - имеет смысл искючительно ради засовывания серверов в
> контенер, который потом можно будет легко брать и переносить между серверами
> (1 физический сервер- 1 виртуальная машина).
> Кстати вам туда надо будет еще и тестовую среду куда-нить засунуть... вот
> ее-то, и можно будет засунуть во второй контейнер.Поддержу. Я бы добавил, если уж сильно хочется виртуализации и прочих прелестей отказоустойчивости глянуть - посмотрите в сторону VmWare с online migration и SAN (хотя бы Еву или LSI2600) в качестве хранилища. Но это не шара, а очень даже вменяемые деньги.
Озадачивайте внедренца. Не стройте велосипед - вам никто спасибо не скажет, а внедренец всегда при провале тыкнет в вас пальцем за ваши костыли.
>[оверквотинг удален]
>> контенер, который потом можно будет легко брать и переносить между серверами
>> (1 физический сервер- 1 виртуальная машина).
>> Кстати вам туда надо будет еще и тестовую среду куда-нить засунуть... вот
>> ее-то, и можно будет засунуть во второй контейнер.
> Поддержу. Я бы добавил, если уж сильно хочется виртуализации и прочих прелестей
> отказоустойчивости глянуть - посмотрите в сторону VmWare с online migration и
> SAN (хотя бы Еву или LSI2600) в качестве хранилища. Но это
> не шара, а очень даже вменяемые деньги.
> Озадачивайте внедренца. Не стройте велосипед - вам никто спасибо не скажет, а
> внедренец всегда при провале тыкнет в вас пальцем за ваши костыли.Я про SAN подумал, и тоже про Еву кстати :) но решил что советовать Еву в данном случае бессмысленно, потому что это совсем не бюджетное решение...
Про кластер - посмотрите в сторону связки drbd+heartbeat. Лично я строил подобную связку на Gentoo для работы биллинга UTM. Кластер обеспечивал бесперебойную работу сервисов - utm5_core, utm5_rfw, mysql, apache. Если интересно - посмотрите описание на сайте разработчиков UTM - www.netup.ru - где-то в разделе документации. Там расписано под Gentoo - но в общем-то выбор дистрибутива не важен. Если подходить к работе творчески, разумеется. :) Собственно, и выбор СУБД тут тоже не важен.
> Вам не приходило в голову задать этот вопрос разработчикам?
>>4 Гб оперативной памяти (лучше 2 планки по 2 Гб, или 1 планка 4 Гб)
> Вы очень мужественный человек, если с такими знаниями беретесь за такую задачу...Меня развеселил Ваш тонкий сарказм. Я постарался изложить все, что рекомендовали мне разработчики, и фраза про 4 Гб взята из их письма. Я знаю, что я - мужественный человек, чего я только не реализовывал с своими знаниями :)
>[оверквотинг удален]
> два раза ХУЖЕ.
> Я бы сделал иначе - отдельно кластер высокой доступности из постргесса средствами
> постгресса (2 или 3 физически разных машины).
> отдельно кластер из двух, физически разных машин для серверов приложений.
> Итого 4 или 5 физических серверов на всю систему.
> Виртуализация в данном случае - имеет смысл искючительно ради засовывания серверов в
> контенер, который потом можно будет легко брать и переносить между серверами
> (1 физический сервер- 1 виртуальная машина).
> Кстати вам туда надо будет еще и тестовую среду куда-нить засунуть... вот
> ее-то, и можно будет засунуть во второй контейнер.Спасибо за предложенную схему(замечу, что я понимаю как работает виртуализация). Если Вас не затруднит, сообщите какое аппаратное обеспечение вы рекомендуете для такой схемы. Все это будет делаться в небольшом государственном ВУЗе, поэтому бюджет ограничен.
> Спасибо за предложенную схему(замечу, что я понимаю как работает виртуализация). Если Вас
> не затруднит, сообщите какое аппаратное обеспечение вы рекомендуете для такой схемы.Это зависит от нагрузки, которую создает система. От объема данных, от сложности sql запросов, от их типа...От нагрузки которую создает сервер приложений, от количества пользователей системы.
Эти данные можно взять у разработчиков, более того, они их обычно предоставляют и настаивают чтобы аппаратное обеспечение соответствовало их рекомендациям.
Иначе - все это сферический конь в вакууме.
Вопрос о том как лучше кластеризировать систему- нужно задать разработчикам системы.
Они должны знать как будет вести себя ситема при росте нагрузки, что нужно сделать для повышения отказоустойчивости.
Не существует сферически-надежного решения, которое можно растиражировать на любую систему и она станет надежной. Есть только общие принципы концепции, некие общие решения, но когда речь заходит о конкретной реализации- все нужно считать и иметь точные цифры.
А они - есть у разработчиков системы и у вас.> Все это будет делаться в небольшом государственном ВУЗе, поэтому бюджет ограничен.
Поскольку данный проект будет работать не один год, то инвестиции в него надо рассчитывать исходя из срока службы проекта, и тогда сумма потраченная на него не будет такой уж большой.
Например вести расчет на 10 лет. То есть первоначальные инвестиции будут приносить пользу в течении 10 лет например. Как все это расчитываестя- знают ваши экономисты.Что касается государственого вуза - то вам надо просто обосновать ваш проект и вам выделят на него деньги. Может и на SAN тоже.
В любом случае, проект должен создаваться исходя из целей а не исходя из имеющихся средств.
Если у вас есть ясная конечная цель, есть ясные расчеты обоснованно доказывающие необходимость инвестиций в этот проект и пользы которую он принесет - вы можете попросить у министерства деньги под него, и вам их дадут.>Я постарался изложить все, что рекомендовали мне разработчики, и фраза про 4 Гб взята из их письма.
Разработчики системы не знают что лучше использоовать, одну банку или две????
Ой!
ОЙ!!!
Серверные материнские платы бывают с поддержкорй двуканальной и трехканальной памяти.
Одну банку они тоже прожуют конечно, но двуканальная память работает быстрее.
Поэтому лучше ставить две банки а еще лучше - три банки, если конкретная материнская плата это поддерживает.