From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43747) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cC0Md-0000AY-SJ for qemu-devel@nongnu.org; Wed, 30 Nov 2016 03:35:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cC0Ma-0005Ld-Nj for qemu-devel@nongnu.org; Wed, 30 Nov 2016 03:35:39 -0500 Received: from mail-wm0-x241.google.com ([2a00:1450:400c:c09::241]:36823) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cC0Ma-0005L9-CL for qemu-devel@nongnu.org; Wed, 30 Nov 2016 03:35:36 -0500 Received: by mail-wm0-x241.google.com with SMTP id m203so28142277wma.3 for ; Wed, 30 Nov 2016 00:35:36 -0800 (PST) Date: Wed, 30 Nov 2016 08:35:33 +0000 From: Stefan Hajnoczi Message-ID: <20161130083533.GA6816@stefanha-x1.localdomain> References: <5DCF5E88-0BC6-443B-B557-9A72D32A4D49@veritas.com> <20161124111135.GC9117@stefanha-x1.localdomain> <20161124160856.GB13535@stefanha-x1.localdomain> <3B08C602-0033-4FCD-AE83-F0962322A7F7@veritas.com> <20161125113508.GC4939@stefanha-x1.localdomain> <995D8EE5-E13C-45C1-A08C-887772D0DEA6@veritas.com> <20161128141756.GC6411@stefanha-x1.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Rakesh Ranjan Cc: ashish mittal , Ketan Nilangekar , Paolo Bonzini , "Daniel P. Berrange" , Jeff Cody , qemu-devel , Kevin Wolf , Markus Armbruster , Fam Zheng , Ashish Mittal , Abhijit Dey , Buddhi Madhav , "Venkatesha M.G." , Nitin Jerath , Gaurav Bhandarkar , Abhishek Kane , Ketan Mahajan , Niranjan Pendharkar , Nirendra Awasthi --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 30, 2016 at 04:20:03AM +0000, Rakesh Ranjan wrote: > >>>>> Why does the client have to know about failover if it's connected to > >>>>>a server process on the same host? I thought the server process > >>>>>manages networking issues (like the actual protocol to speak to other > >>>>>VxHS nodes and for failover). >=20 > Just to comment on this, the model being followed within HyperScale is to > allow application I/O continuity (resiliency) in various cases as > mentioned below. It really adds value for consumer/customer and tries to > avoid culprits for single points of failure. >=20 > 1. HyperScale storage service failure (QNIO Server) > - Daemon managing local storage for VMs and runs on each compute node > - Daemon can run as a service on Hypervisor itself as well as within VSA > (Virtual Storage Appliance or Virtual Machine running on the hypervisor), > which depends on ecosystem where HyperScale is supported > - Daemon or storage service down/crash/crash-in-loop shouldn=B9t lead to= an > huge impact on all the VMs running on that hypervisor or compute node > hence providing service level resiliency is very useful for > application I/O continuity in such case. >=20 > Solution: > - The service failure handling can be only done at the client side and > not at the server side since service running as a server itself is down. > - Client detects an I/O error and depending on the logic, it does > application I/O failover to another available/active QNIO server or > HyperScale Storage service running on different compute node > (reflection/replication node) > - Once the orig/old server comes back online, client gets/receives > negotiated error (not a real application error) to do the application I/O > failback to the original server or local HyperScale storage service to get > better I/O performance. > =20 > 2. Local physical storage or media failure > - Once server or HyperScale storage service detects the media or local > disk failure, depending on the vDisk (guest disk) configuration, if > another storage copy is available > on different compute node then it internally handles the local > fault and serves the application read and write requests otherwise > application or client gets the fault. > - Client doesn=B9t know about any I/O failure since Server or Storage > service manages/handles the fault tolerance. > - In such case, in order to get some I/O performance benefit, once > client gets a negotiated error (not an application error) from local > server or storage service, > client can initiate I/O failover and can directly send > application I/O to another compute node where storage copy is available to > serve the application need instead of sending it locally where media is > faulted. =20 Thanks for explaining the model. The new information for me here is that the qnio server may run in a VM instead of on the host and that the client will attempt to use a remote qnio server if the local qnio server fails. This means that although the discussion most recently focussed on local I/O tap performance, there is a requirement for a network protocol too. The local I/O tap stuff is just an optimization for when the local qnio server can be used. Stefan --cWoXeonUoKmBZSoM Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJYPo9VAAoJEJykq7OBq3PIDlgIAMQ9F8uiYNRYBVPcORetp7r/ jWGH5ildrMs3CEJHDN9WW41oEU5Yjl6ayRZh6U4gEp0p/985fY5gq9afo82ETWqQ iVE3KuZbv1dJMw9aJfD7ztH26bxohpzJg3HD3VlbogY9fa0+j/srwJ2UyOP4SWBa bwYtvFAtGnlghZbrJiS5d9FsPo8HCMa9bXaRMZtjO5mJ9lSAtIibuq7IqmW0Qfj2 v+Mzs4wZIzQY8/QpQeOw16xksrA6ZYtAFeGgW+sQOg88z5P1LsFZfcBuWT6wVtd5 9F0ZEb+AnKjWgRs/uvgH1MYrcd8hbgXnK2TNsMSnGiYuj34XdPuKcFR4BvcufVw= =g3L5 -----END PGP SIGNATURE----- --cWoXeonUoKmBZSoM--