Поднять одну виртуальную машину на двух физических серверах.
винду и 1с.вроде же 1с на линух ставится, не?
Нужная фича называется live migration или завязана на нее.
по википедии:
VM managers with live migration support
Virtuozzo
Xen
OpenVZ
Workload Partitions
Integrity Virtual Machines
KVM
Oracle VM
Oracle VM for Sparc
POWER Hypervisor (PHYP)
VMware ESX
IBM VPAR with special migrator
Hyper-V Server 2008 R2
VirtualBox
Реального опыта увы нет, разок только виртуалку на ксене переносил. И то кажется без небольшого даунтайма не обошлось.
по википедии:
VM managers with live migration support
Virtuozzo
Xen
OpenVZ
Workload Partitions
Integrity Virtual Machines
KVM
Oracle VM
Oracle VM for Sparc
POWER Hypervisor (PHYP)
VMware ESX
IBM VPAR with special migrator
Hyper-V Server 2008 R2
VirtualBox
Реального опыта увы нет, разок только виртуалку на ксене переносил. И то кажется без небольшого даунтайма не обошлось.
вроде же 1с на линух ставится, не?Если есть хорошие решения под нужную задачу на Линуксе, то сгодится и Линукс. По умолчанию компания работает на винде.
нормальное решение, которое применяется в enterprise - это failover clustering
http://technet.microsoft.com/en-us/library/ff182338%28v=ws.1...
оно конечно потребует физических и софтовых ресурсов
http://technet.microsoft.com/en-us/library/ff182338%28v=ws.1...
оно конечно потребует физических и софтовых ресурсов
А сколько по деньгам выйдет примерно ?
это лучше запрос к вендору отправить
еще есть вариант - облачный хостинг серверов. мы собственно к нему пришли и думаю, что этот рынок будет расширяться сильно в будущем
еще есть вариант - облачный хостинг серверов. мы собственно к нему пришли и думаю, что этот рынок будет расширяться сильно в будущем
в облаке уже хостимся, тут сервис критичный и завязывать его на стабильность инет-канала как-то не хочется. Т.е. в облако максимум бекапы баз сливать может раз в день, сама 1с-ка должна локально крутиться.
drbd плюс xen/kvm ваш выбор - из говна и палок получится сделать решение на уровне отказоустойчивости целой машины - то есть ситуация "блок питания сгорел" будет видеться как перезагрузка инстанса, это если хотите приобщиться к опенсорсу, если заплатить денег мс - вариант . BTW, очевидно, что выбор хост-системы никак не завязан с гостевой, потому линукс-не линукс с одинэсом - пофигу, можно оставить ту же винду. Кластерную фс предлагать смысла нет, сложно и масштабы не те.
Ну вон есть xen с live migration, в целом любая современная система виртуализации это умеет, вопрос в религии и любови к интерфейсам, xen конфигурится удобней всего через консоль, есть всякие xen server и vmware, там уже есть какая-никакая гуя.
То, про что написал для решения m$ у VMWare называется в зависимости от бюждета либо High Availability:
http://www.vmware.com/products/high-availability/overview.ht...
, либо Fault Tolerance:
http://www.vmware.com/products/fault-tolerance/overview.html
В одном случае, как и писалось выше, при выходе из строя одного физического сервера виртуалки "моментально" поднимаются на втором, а у пользователя это выглядит как подрыв сессии. Во втором случае виртуалка работает сразу на двух серверах и при выходе одного из них из строя с точки зрения пользователя НИЧЕГО не происходит.
Денег стоит примерно вот так:
http://www.vmware.com/products/vsphere/pricing.html — для HA нужен Essentials Plus, а для FT — Enterprise Acceleration
На всякий случай: вот развёрнуто разница между этими пакетами: http://www.vmware.com/products/datacenter-virtualization/vsp...
http://www.vmware.com/products/high-availability/overview.ht...
, либо Fault Tolerance:
http://www.vmware.com/products/fault-tolerance/overview.html
В одном случае, как и писалось выше, при выходе из строя одного физического сервера виртуалки "моментально" поднимаются на втором, а у пользователя это выглядит как подрыв сессии. Во втором случае виртуалка работает сразу на двух серверах и при выходе одного из них из строя с точки зрения пользователя НИЧЕГО не происходит.
Денег стоит примерно вот так:
http://www.vmware.com/products/vsphere/pricing.html — для HA нужен Essentials Plus, а для FT — Enterprise Acceleration
На всякий случай: вот развёрнуто разница между этими пакетами: http://www.vmware.com/products/datacenter-virtualization/vsp...
Судя по описанию самый дешевый пакет VMware vSphere Essentials Kit поддерживает v-motion. Я так понял, что на этой технологии можно сделать live migration виртуалок с хоста на хост. Или я что-то не так понял ?
Во втором случае виртуалка работает сразу на двух серверах и при выходе одного из них из строя с точки зрения пользователя НИЧЕГО не происходит.
Репликация будет с некоторой задержкой, это не rdma + зеркалирование памяти. Впрочем, если из-за ребута инстанса потеряется очень много денег, такой вариант оптимальный - дешевле блейда с шиной с поддержкой rdma и при этом довольно быстро
Еще тут нужен внешний сторедж, что увеличивает число задействованных железяк минимум до 3.ребут допустим, задержка в работе в 2-3 минуты не особо критична.
Да, можно, но будет некоторый даунтайм.
И! Для работы vMotion требуется Shared storage — т.е. ОБЩЕЕ СЕТЕВОЕ ХРАНИЛИЩЕ. Если это не нужно/дорого/не оправдано, то нужен Storage vMotion. НО! Со Storage vMotion в случае выхода из строя сервера, где работает виртуалка двигать будет просто-напросто нечего.
И! Для работы vMotion требуется Shared storage — т.е. ОБЩЕЕ СЕТЕВОЕ ХРАНИЛИЩЕ. Если это не нужно/дорого/не оправдано, то нужен Storage vMotion. НО! Со Storage vMotion в случае выхода из строя сервера, где работает виртуалка двигать будет просто-напросто нечего.
У VMware и на это есть ответ: VSA - Virtual Storage Appliance, который из внутренних дисков ESXi собирает общий storage.
Да, есть
http://www.vmware.com/products/datacenter-virtualization/vsp...
, но чего-то когда я пробовал, меня производительность не впечатлила, хотя может это была просто кривость рук.
http://www.vmware.com/products/datacenter-virtualization/vsp...
, но чего-то когда я пробовал, меня производительность не впечатлила, хотя может это была просто кривость рук.
VSA - Virtual Storage ApplianceДорогой собака. 5к$ за essentials plus где это есть превышает бюджеты.
High Availibility вещь вообще дорогая... 
Можно вот такой сервер взять:
http://www.stratus.com/Products/ftServerSystems.aspx
Можно вот такой сервер взять:
http://www.stratus.com/Products/ftServerSystems.aspx
drbd бесплатный
тебе ж написали уже все ключевые слова
тебе ж написали уже все ключевые слова
Не проще ли обеспечить failover базы данных (1с на постгресе кажись? а на виртуалках поднимать только сам сервер 1с. Поскольку все данные надежно сохранены в БД, сами виртуалки можно будет синхронизировать не в режиме реального времени, а по мере надобности - после апдейтов и тд. То есть речь о замене живой репликации виртуалок живой репликацией БД, что и проще и дешевле.
А как ты представляешь конструкцию в плане железяк? Пока не очень понятно.
как пример (об 1с имею смутное представление):
2 сервака на линуксе с постгресом в режиме failover - один основной, второй реплика. Все критичные данные тут, живая репликация и бэкап средствами постгрес. Это бэкэнд для 1с, все критичные и изменяемые данные тут.
На них же поднимается и сам 1с. Если нативная линуксовая версия - репликация его файлов и файловер стандартными линуксовыми средствами. Если поднимать в виртуалке - то сложнее, надо копировать виртуалку с хоста на хост. Но надобность в живой репликации, что виртуалок что нативной версии, все равно отпадает - тут критичных или постоянно изменяемых данных нет.
2 сервака на линуксе с постгресом в режиме failover - один основной, второй реплика. Все критичные данные тут, живая репликация и бэкап средствами постгрес. Это бэкэнд для 1с, все критичные и изменяемые данные тут.
На них же поднимается и сам 1с. Если нативная линуксовая версия - репликация его файлов и файловер стандартными линуксовыми средствами. Если поднимать в виртуалке - то сложнее, надо копировать виртуалку с хоста на хост. Но надобность в живой репликации, что виртуалок что нативной версии, все равно отпадает - тут критичных или постоянно изменяемых данных нет.
На них же поднимается и сам 1с.При таком раскладе придется платить за 2 sql лицензии 1с, это +30к к бюджету. Хотя за идею спасибо, подумаю.
При таком раскладе придется платить за 2 sql лицензии 1с, это +30к к бюджету. Хотя за идею спасибо, подумаю.Почему 2? База данных ведь одна, то что она на двух серваках среплицирована, 1с волновать не должно. Виртуалка в произвольный момент времени тоже запущена только одна.
1с волновать не должноее волнует число оновременно запущенных копий 1с (если в настивном linux режиме) . Если виртуалки, то гипервизор на какую машинку ставить?
ее волнует число оновременно запущенных копий 1с (если в настивном linux режиме) . Если виртуалки, то гипервизор на какую машинку ставить?Так лучше же нативную ставить при прочих равных, зачем усложнять жизнь гипервизором. Одновременно будет запущена только одна копия 1с сервера. Но установлена, идентичным образом настроена и регулярно синхронизируема на оба сервера.
Так лучше же нативную ставить при прочих равных, зачем усложнять жизнь гипервизором. Одновременно будет запущена только одна копия 1с сервера. Но установлена, идентичным образом настроена и регулярно синхронизируема на оба сервера.А при падении одного из серваков, ключ usb защиты руками перетыкать во второй ?
Ща у 1С есть ещё какие то варианты програмной защиты (я так думаю, появились из за чрезвычайной сложности проброса usb в виртуальные машины промышленных гипервизоров но я сомневаюсь что один ключ программной защиты можно активировать сразу на 2-х серверах.
ps. Сервер 1С требует нахождения серверного ключа именно в машине, на которой он работает.
ps2. Вообще наверное самая простая и эффективная схема. Репликация баз данных средствами mssql/postgresql + 2 автономных сервера 1С настроенных использовать Бд ближайшего субд. Если перед всем этим хозяйством воткнуть простенький маршрутизатор, следящий за здоровьем нод и автоматически начинающим форвардить сессии 1С к запасной ноде при падении главной - то выход из строя ноды скажется лишь падением всех текущих 1с сессий, поидее. (т.е. клиент выдаст сообщение о принудительном отключении, но его можно будет перезапустить и продолжить работу).
Оставить комментарий
Gulveig
Возникла необходимость максимально возможную за разумные деньги отказоустойчивость критичного сервиса (сервер 1с на ~5 пользователей). Администрирование максимум будет удаленное, физический доступ к железкам после запуска в эксплуатацию затруднен.Пока на ум приходит поднять виртуалку на двух физических хостах (два одинаковых сервачка) и на нее уже винду и 1с. Плюс регулярно бекапить БД в облако.
Существуют ли бесплатные/недорогие решение позволяющие это сделать?
Или же можно как-то иначе зарезервировать сервис, дабы неквалифицированный персонал смог восстановить работоспособность в случае умирания одного из серверов? Максимум на что можно рассчитывать: нажатие ресета, перетыкание сетевого кабеля из одной машинки в другую.