Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 209A7200D5F for ; Mon, 18 Dec 2017 11:01:54 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 1F111160C05; Mon, 18 Dec 2017 10:01:54 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 3B9B4160BF9 for ; Mon, 18 Dec 2017 11:01:53 +0100 (CET) Received: (qmail 75777 invoked by uid 500); 18 Dec 2017 10:01:51 -0000 Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cloudstack.apache.org Delivered-To: mailing list dev@cloudstack.apache.org Received: (qmail 75734 invoked by uid 99); 18 Dec 2017 10:01:51 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Dec 2017 10:01:51 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 8ECE8C2F88; Mon, 18 Dec 2017 10:01:50 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.879 X-Spam-Level: * X-Spam-Status: No, score=1.879 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id ok6ozQ0BlmlT; Mon, 18 Dec 2017 10:01:48 +0000 (UTC) Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com [209.85.218.49]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 735655F19D; Mon, 18 Dec 2017 10:01:47 +0000 (UTC) Received: by mail-oi0-f49.google.com with SMTP id s9so10207233oie.5; Mon, 18 Dec 2017 02:01:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TN/ec3/cBMuoRpQaznbS/fvOPj8nZEuL3/GgDfii9Ns=; b=NU4swEG4WCsA8MejUnf4frSx+WXDNoQTtcL2aiodp02g7gFsxfXXOlhernZ9/dOHOF 7bD9ICaIvxJYS+a8zt33VbFrMYX0HfPtGiHsdb0uwDelOvs9GIDtLQaXlnmD9FNhe3UU +036ntvAB6avxVrfwYCzXKjKhesDNmTIss3PmYVXs3hRoGscwHVh4Dy+LdIMxvf2Ujhu Im1j0fHXv0yKea8L4WL1NX5XiedSNzHed1zUpKJ3r8SEJLtOi2UgTR0muKNaulG34ZFL k0rPbFGTbwyKV71pB1yPK9PYTho+F25qbQNJdICsvKn4I/zEfgqlh7RZsuYkOeDvtMZJ QbcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TN/ec3/cBMuoRpQaznbS/fvOPj8nZEuL3/GgDfii9Ns=; b=CoiJHWKjadFQWBNeJkJN5IPSVkTyvWBe//Adp9JZzlr4fZFY5SnuT74auGssPsF/Z2 axAzfOKaSLLCibhq8MuRJVq+AwHe/Sqb6NduAiatBu/e5qSdNduBSnfvA3wDeAGX8Lfa zsqMXzqHGgJdAlUR94Ksrje/R2bETbmg8ARQOKWUxuU24jgxwuzxOL8v3IVuQQCTkxal h3vO2BTEl54pd1Tsa9RNydBgMytgs8Lcs4C7dfbiV5K/XgTNfTJLlo24uHSHxycRUnnk oEvt205q4aHhP+H7MO4hrOh40pkmskm2IdFyIVGs3Z6eLL4DjalEkvdMaG0b/UN5Oid9 6MLQ== X-Gm-Message-State: AKGB3mJFPMbjLspJVkq11DuNUPq25JsEPepivXYqb6vOG47Z9205lyA9 MnCjcH0KGT/GpKfJUTMFMtGMCLRWxZe9OXV7y2Ewi/p2 X-Google-Smtp-Source: ACJfBotzr2Ak4borENfJ8d0XU2tnn8/wDYTjwp8USgx8fyvEr8IPvMI+D9O/7j1ck+nTpUs3fmNjpRHkn9bZKbXrdOs= X-Received: by 10.202.168.197 with SMTP id r188mr4207345oie.262.1513591299348; Mon, 18 Dec 2017 02:01:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.64.181 with HTTP; Mon, 18 Dec 2017 02:01:38 -0800 (PST) In-Reply-To: References: From: =?UTF-8?Q?Rafael_Weing=C3=A4rtner?= Date: Mon, 18 Dec 2017 08:01:38 -0200 Message-ID: Subject: Re: [Discuss] Management cluster / Zookeeper holding locks To: "users@cloudstack.apache.org" Cc: "dev@cloudstack.apache.org" Content-Type: multipart/alternative; boundary="001a113cbd44bb9e8305609a6fe8" archived-at: Mon, 18 Dec 2017 10:01:54 -0000 --001a113cbd44bb9e8305609a6fe8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Do we have framework to do this kind of looking in ZK? I mean, you said " create a new InterProcessSemaphoreMutex which handles the locking mechanism.". This feels that we would have to continue opening and closing this transaction manually, which is what causes a lot of our headaches with transactions (it is not MySQL locks fault entirely, but our code structure). On Mon, Dec 18, 2017 at 7:47 AM, Marc-Aur=C3=A8le Brothier wrote: > We added ZK lock for fix this issue but we will remove all current locks = in > ZK in favor of ZK one. The ZK lock is already encapsulated in a project > with an interface, but more work should be done to have a proper interfac= e > for locks which could be implemented with the "tool" you want, either a D= B > lock for simplicity, or ZK for more advanced scenarios. > > @Daan you will need to add the ZK libraries in CS and have a running ZK > server somewhere. The configuration value is read from the > server.properties. If the line is empty, the ZK client is not created and > any lock request will immediately return (not holding any lock). > > @Rafael: ZK is pretty easy to setup and have running, as long as you don'= t > put too much data in it. Regarding our scenario here, with only locks, it= 's > easy. ZK would be only the gatekeeper to locks in the code, ensuring that > multi JVM can request a true lock. > For the code point of view, you're opening a connection to a ZK node (any > of a cluster) and you create a new InterProcessSemaphoreMutex which handl= es > the locking mechanism. > > On Mon, Dec 18, 2017 at 10:24 AM, Ivan Kudryavtsev < > kudryavtsev_ia@bw-sw.com > > wrote: > > > Rafael, > > > > - It's easy to configure and run ZK either in single node or cluster > > - zookeeper should replace mysql locking mechanism used inside ACS code > > (places where ACS locks tables or rows). > > > > I don't think from the other size, that moving from MySQL locks to ZK > locks > > is easy and light and (even implemetable) way. > > > > 2017-12-18 16:20 GMT+07:00 Rafael Weing=C3=A4rtner < > rafaelweingartner@gmail.com > > >: > > > > > How hard is it to configure Zookeeper and get everything up and > running? > > > BTW: what zookeeper would be managing? CloudStack management servers = or > > > MySQL nodes? > > > > > > On Mon, Dec 18, 2017 at 7:13 AM, Ivan Kudryavtsev < > > > kudryavtsev_ia@bw-sw.com> > > > wrote: > > > > > > > Hello, Marc-Aurele, I strongly believe that all mysql locks should = be > > > > removed in favour of truly DLM solution like Zookeeper. The > performance > > > of > > > > 3node ZK ensemble should be enough to hold up to 1000-2000 locks pe= r > > > second > > > > and it helps to move to truly clustered MySQL like galera without > > single > > > > master server. > > > > > > > > 2017-12-18 15:33 GMT+07:00 Marc-Aur=C3=A8le Brothier : > > > > > > > > > Hi everyone, > > > > > > > > > > I was wondering how many of you are running CloudStack with a > cluster > > > of > > > > > management servers. I would think most of you, but it would be ni= ce > > to > > > > hear > > > > > everyone voices. And do you get hosts going over their capacity > > limits? > > > > > > > > > > We discovered that during the VM allocation, if you get a lot of > > > parallel > > > > > requests to create new VMs, most notably with large profiles, the > > > > capacity > > > > > increase is done too far after the host capacity checks and resul= ts > > in > > > > > hosts going over their capacity limits. To detail the steps: the > > > > deployment > > > > > planner checks for cluster/host capacity and pick up one deployme= nt > > > plan > > > > > (zone, cluster, host). The plan is stored in the database under a > > > VMwork > > > > > job and another thread picks that entry and starts the deployment= , > > > > > increasing the host capacity and sending the commands. Here > there's a > > > > time > > > > > gap between the host being picked up and the capacity increase fo= r > > that > > > > > host of a couple of seconds, which is well enough to go over the > > > capacity > > > > > on one or more hosts. A few VMwork job can be added in the DB que= ue > > > > > targeting the same host before one gets picked up. > > > > > > > > > > To fix this issue, we're using Zookeeper to act as the multi JVM > lock > > > > > manager thanks to their curator library ( > > > > > https://curator.apache.org/curator-recipes/shared-lock.html). We > > also > > > > > changed the time when the capacity is increased, which occurs now > > > pretty > > > > > much after the deployment plan is found and inside the zookeeper > > lock. > > > > This > > > > > ensure we don't go over the capacity of any host, and it has been > > > proven > > > > > efficient since a month in our management server cluster. > > > > > > > > > > This adds another potential requirement which should be discuss > > before > > > > > proposing a PR. Today the code works seamlessly without ZK too, t= o > > > ensure > > > > > it's not a hard requirement, for example in a lab. > > > > > > > > > > Comments? > > > > > > > > > > Kind regards, > > > > > Marc-Aur=C3=A8le > > > > > > > > > > > > > > > > > > > > > -- > > > > With best regards, Ivan Kudryavtsev > > > > Bitworks Software, Ltd. > > > > Cell: +7-923-414-1515 > > > > WWW: http://bitworks.software/ > > > > > > > > > > > > > > > > -- > > > Rafael Weing=C3=A4rtner > > > > > > > > > > > -- > > With best regards, Ivan Kudryavtsev > > Bitworks Software, Ltd. > > Cell: +7-923-414-1515 > > WWW: http://bitworks.software/ > > > --=20 Rafael Weing=C3=A4rtner --001a113cbd44bb9e8305609a6fe8--