Hello! Really! Nice feedback! ZFS live migration could be implemented with current ZFS version by multiple calls of zfs send/receive with multiple snapshots.
But I created issue to ZFS On Linux project about more convenient way to do this task: https://github.com/zfsonlinux/zfs/issues/3407 --- Docker is awesome toolkit. But we still haven't support for in OpenVZ/PCS. I'm really _NOT_ sure about idea to run Docker inside container. I want to run it on HWN (together with another containers if possible) and run my custom applications in a securely manner here. Running Docker inside containers is really strange idea and I haven't any use cases for it in my environment. On Wed, May 13, 2015 at 4:03 AM, Gena Makhomed <g...@csdoc.com> wrote: > On 13.05.2015 2:09, Pavel Odintsov wrote: > >> Completely disagree with "After hitting bug >> https://bugzilla.openvz.org/show_bug.cgi?id=2470 I completely disable >> suspending on stop for all hardware nodes, - "VE_STOP_MODE=stop" in >> /etc/vz/vz.conf and don't use it at all." > > > Sorry, but I really set "VE_STOP_MODE=stop" in /etc/vz/vz.conf > because checkpointing too slow on my hardware for many containers > and HDD disks without SSD, and just stop/start is much faster > than suspend/resume all CT for hardware node reboot. > So, "VE_STOP_MODE=stop" provides minimal downtime. > > And yes, bug https://bugzilla.openvz.org/show_bug.cgi?id=2470 > prevents starting nginx after CT resume after hardware node reboot. > I need most stable/reliable server - this is the first line priority. > >> We use cpt/rst for ten of thousands containers for few years. And in >> 99.9% cases it works with charm. And it's one os most killer features >> of OpenVZ. > > > But why I need to use cpt/rst with OpenVZ ? > CT must be online and uptime always, without downtimes during cpt/rst. > If CT is completely damaged/broken - I just restore it from backup. > > --- > > If you talk about live migration of CT between hardware nodes - > I can't easy use this feature with current main hosting provider: > > Hetzner allow only max 3 Failover IPs, with € 4.20 / month > price for each IP and additional € 12.61 / month for Flexi-Pack. > more details here: http://wiki.hetzner.de/index.php/Failover/en > > Also bash script for swithing IP between servers is not trivial: > http://wiki.hetzner.de/index.php/Failover_Skript/en > > And Hetzner Failover subnet can't be used with OpenVZ, > because "A failover subnet can only be switched as a whole, > single IPs from the subnet can not be switched individually". > > So using CT live migration with Hetzner is looks like very costly > and limited solution - max only 3 OpenVZ CT can be live migrated. > > May be other hosting provides has other restrictions, but right now > I mostly use Hetzher.de as the winner for price/performance ratio > after protecting most valuable sites from DDoS via CloudFlare.com > > --- > > Also the main reason why I can't use OpenVZ live migration > is incompatibility between OpenVZ live migration and ZFS, > as I understand - for live migration I must use ploop images > located on ext4 filesystems and can't use simfs on top of ZFS. > > But ZFS is most natural way to get optimal price/performance ratio, > with very high level of reliability of storage subsystem based on > slow big HDDs and fast SSDs for ZFS L2ARC. > > So, evaluate benefits of ZFS and OpenVZ live migration > I should select ZFS and can't use live migration at all. > > --- > > Now, as I understand, main trend in DevOps / Continuous Delivery > is approach http://martinfowler.com/bliki/ImmutableServer.html > with on-fly switching between online instances via method of > http://martinfowler.com/bliki/BlueGreenDeployment.html > > And many new userland utilites are now created for this purposes: > for example, Docker.com and coreos/rkt with App Container: > http://www.opennet.ru/opennews/art.shtml?num=41168 > http://www.opennet.ru/opennews/art.shtml?num=41545 > > As for me, ideal server is Linux hardware node with ability > to run on top of it KVM virtual machines, OpenVZ containers, > and probably some Application Container Specification Implementations > inside OpenVZ containers and on top of hardware nodes simultaneously. > > This will allow seamless migration from KVM-based Linux virtual machines > to OpenVZ containers and in future - also seamless software migration > from OpenVZ CTs to App Container Images and App Container Runtimes. > > -- > Best regards, > Gena > > > _______________________________________________ > Users mailing list > Users@openvz.org > https://lists.openvz.org/mailman/listinfo/users -- Sincerely yours, Pavel Odintsov _______________________________________________ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users
