回复: CloudStack4.4.3 安装失败【Requires: java7】
CenOS6.5默认的java应该是1.6的，而cloudstack4.4以上的版本要求java1.7 你说先安装了java1.7，再安装cloudstack。此时你查看下java的版本 你的1.7版本是否生效，还是被cloudstack卸载掉了。 你可以在安装cloudstack完成后，卸载原有的java 安装1.7版java 再启动cloudstack服务 王海成 公司名称：华茂云天科技（北京）有限公司 公司地址：北京市朝阳区酒仙桥东路9号院A1楼一层100015 Email：wang...@cniaas.com 电话：13681545982 发件人： zhangyan 发送时间： 2015-06-05 10:37 收件人： users-cn@cloudstack.apache.org 主题： CloudStack4.4.3 安装失败【Requires: java7】 CentOS6.5下利用系统盘做本地yum源，安装CloudStack，报错Requires: java7，如何 解决？？？ 先用yum安装java-1.7.0-openjdk-1.7.0.45-2.4.3.3.el6.x86_64 或者 jdk-7u79-linux-x64.rpm，再安装cloustack-management还是不行，为什么？ ~ -- Processing Dependency: java7 for package: cloudstack-management-4.4.3-shapeblue0.el6.x86_64 --- Package kernel-headers.x86_64 0:2.6.32-431.el6 will be installed -- Finished Dependency Resolution Error: Package: cloudstack-management-4.4.3-shapeblue0.el6.x86_64 (cloudstack) Requires: java7 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest --- Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged of Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying is strictly prohibited, and may be unlawful.If you have received this communication in error,please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. ---
Re: database high availability question vs haproxy
Hi Simon, thanks for the link - actually I have already read this - but Im still seaking for some answeres :) : - real world experience with DB HA in general - is i better to use haproxy(clustered/redudant) for mysql towards Galera cluster - or simply to reference 2 nodes (1 as master, another as slave) with native ACS DB HA - silly question but anyway... - my understanding - ACS just pings and connects to master or slave (all replication etc, is done from my side, not from ACS) ? Thanks again and any info is greatly appreciated. Andrija On 4 June 2015 at 16:23, Simon Weller swel...@ena.com wrote: Andrija, Here is the original design document, and it should give you a better idea of what is implemented today: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=34838207 We have plans to test this in our lab soon, but just haven't got around to it yet. - Si From: Andrija Panic andrija.pa...@gmail.com Sent: Thursday, June 4, 2015 9:08 AM To: d...@cloudstack.apache.org; users@cloudstack.apache.org Subject: Re: database high availability question vs haproxy Anyone :) ? On 31 May 2015 at 00:26, Andrija Panic andrija.pa...@gmail.com wrote: Hi, I would have a question on database HA feature in db.properties ( http://cloudstack-administration.readthedocs.org/en/latest/reliability.html#configuring-database-high-availability ) If I understand correctly, it is up to the admin to provide appropriate mysql HA (active-active, galera, etc) and ACS management server will JUST try to connect to slaves if the master is down ? We are running Galera, with haproxy/keepalived, and by using stoping haproxy, it takes i.e. 6sec for keepalived to detect haproxy is down, and failover IP to another host. During these 6 seconds, ACS managemnt server goes dead, because of this DB unavailability. So my wondering, is better to use ACS db HA feature, instead of loadbalancer for this specific purpose ? (we are also using haproxy/keepalived for management server loadbalancing - 2 servers in backend...) Any experience shared is really appreciated ! -- Andrija Panić -- Andrija Panić -- Andrija Panić
Re: database high availability question vs haproxy
Thanks Simon - that is what I thought... So my question would be then, haproxy vs native ACS/mysql connector going to galera1/galera2/etc...will figure out, for now we use haproxy for mysql/galera loadbalancing... THanks a lot Simon, Andrija On 5 June 2015 at 15:18, Simon Weller swel...@ena.com wrote: Personally, I think that Gallera is always going to be a safer option, as it handles conflict resolution natively. Having said that, it appears care has been taken in designing the ACS MGMT DB integration so that the chance of conflicts is very low. Galera requires a 3 nodes minimum, so it's a lot of hardware unless you've got plans to use it elsewhere in your organisation. The downside to Galera, is that it's synchronous replication, so it needs very low latency between nodes. That doesn't make it a good candidate for geographic separation between DB nodes for a DR scenario. You're understanding of the replication structure, as based on the design document is correct. MySQL (or Galera) handles all the replication. ACS just handles which node it's writing and reading from. In a 2 node native MySQL cluster, it's expected that you are setup for cross master-master replication. - Si From: Andrija Panic andrija.pa...@gmail.com Sent: Friday, June 5, 2015 2:41 AM To: d...@cloudstack.apache.org Cc: users@cloudstack.apache.org Subject: Re: database high availability question vs haproxy Hi Simon, thanks for the link - actually I have already read this - but Im still seaking for some answeres :) : - real world experience with DB HA in general - is i better to use haproxy(clustered/redudant) for mysql towards Galera cluster - or simply to reference 2 nodes (1 as master, another as slave) with native ACS DB HA - silly question but anyway... - my understanding - ACS just pings and connects to master or slave (all replication etc, is done from my side, not from ACS) ? Thanks again and any info is greatly appreciated. Andrija On 4 June 2015 at 16:23, Simon Weller swel...@ena.com wrote: Andrija, Here is the original design document, and it should give you a better idea of what is implemented today: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=34838207 We have plans to test this in our lab soon, but just haven't got around to it yet. - Si From: Andrija Panic andrija.pa...@gmail.com Sent: Thursday, June 4, 2015 9:08 AM To: d...@cloudstack.apache.org; users@cloudstack.apache.org Subject: Re: database high availability question vs haproxy Anyone :) ? On 31 May 2015 at 00:26, Andrija Panic andrija.pa...@gmail.com wrote: Hi, I would have a question on database HA feature in db.properties ( http://cloudstack-administration.readthedocs.org/en/latest/reliability.html#configuring-database-high-availability ) If I understand correctly, it is up to the admin to provide appropriate mysql HA (active-active, galera, etc) and ACS management server will JUST try to connect to slaves if the master is down ? We are running Galera, with haproxy/keepalived, and by using stoping haproxy, it takes i.e. 6sec for keepalived to detect haproxy is down, and failover IP to another host. During these 6 seconds, ACS managemnt server goes dead, because of this DB unavailability. So my wondering, is better to use ACS db HA feature, instead of loadbalancer for this specific purpose ? (we are also using haproxy/keepalived for management server loadbalancing - 2 servers in backend...) Any experience shared is really appreciated ! -- Andrija Panić -- Andrija Panić -- Andrija Panić -- Andrija Panić
Re: database high availability question vs haproxy
Personally, I think that Gallera is always going to be a safer option, as it handles conflict resolution natively. Having said that, it appears care has been taken in designing the ACS MGMT DB integration so that the chance of conflicts is very low. Galera requires a 3 nodes minimum, so it's a lot of hardware unless you've got plans to use it elsewhere in your organisation. The downside to Galera, is that it's synchronous replication, so it needs very low latency between nodes. That doesn't make it a good candidate for geographic separation between DB nodes for a DR scenario. You're understanding of the replication structure, as based on the design document is correct. MySQL (or Galera) handles all the replication. ACS just handles which node it's writing and reading from. In a 2 node native MySQL cluster, it's expected that you are setup for cross master-master replication. - Si From: Andrija Panic andrija.pa...@gmail.com Sent: Friday, June 5, 2015 2:41 AM To: d...@cloudstack.apache.org Cc: users@cloudstack.apache.org Subject: Re: database high availability question vs haproxy Hi Simon, thanks for the link - actually I have already read this - but Im still seaking for some answeres :) : - real world experience with DB HA in general - is i better to use haproxy(clustered/redudant) for mysql towards Galera cluster - or simply to reference 2 nodes (1 as master, another as slave) with native ACS DB HA - silly question but anyway... - my understanding - ACS just pings and connects to master or slave (all replication etc, is done from my side, not from ACS) ? Thanks again and any info is greatly appreciated. Andrija On 4 June 2015 at 16:23, Simon Weller swel...@ena.com wrote: Andrija, Here is the original design document, and it should give you a better idea of what is implemented today: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=34838207 We have plans to test this in our lab soon, but just haven't got around to it yet. - Si From: Andrija Panic andrija.pa...@gmail.com Sent: Thursday, June 4, 2015 9:08 AM To: d...@cloudstack.apache.org; users@cloudstack.apache.org Subject: Re: database high availability question vs haproxy Anyone :) ? On 31 May 2015 at 00:26, Andrija Panic andrija.pa...@gmail.com wrote: Hi, I would have a question on database HA feature in db.properties ( http://cloudstack-administration.readthedocs.org/en/latest/reliability.html#configuring-database-high-availability ) If I understand correctly, it is up to the admin to provide appropriate mysql HA (active-active, galera, etc) and ACS management server will JUST try to connect to slaves if the master is down ? We are running Galera, with haproxy/keepalived, and by using stoping haproxy, it takes i.e. 6sec for keepalived to detect haproxy is down, and failover IP to another host. During these 6 seconds, ACS managemnt server goes dead, because of this DB unavailability. So my wondering, is better to use ACS db HA feature, instead of loadbalancer for this specific purpose ? (we are also using haproxy/keepalived for management server loadbalancing - 2 servers in backend...) Any experience shared is really appreciated ! -- Andrija Panić -- Andrija Panić -- Andrija Panić
Re: database high availability question vs haproxy
Exactly...thanks Simon for the time and help :) Is there any mysql timeout/retry parameter that is set in db.properties (like db.cloud.queriesBeforeRetryMaster=5000), but I'm wondering since I'm using keepalived/haproxy setup, it takes up to 5-6 sec for keepalive to detect haproxy is down (while testing I shutdown haproxu on active node), and then keepalvied moves IP to another node - meaning I have 5-6sec of no connection between ACS mgmt servers and database/haproxy. Is this timeout configurabile on ACS/mysql connector side ? Thanks again, Andrija On 5 June 2015 at 15:54, Simon Weller swel...@ena.com wrote: I think haproxy is a better design in my opinion. You're going to have to use haproxy to balance the host agents to multiple management servers anyway, so you'll already be using it. haproxy can then manage the health checks to Galera rather than over complicating it with the CS Management configuration. - Si From: Andrija Panic andrija.pa...@gmail.com Sent: Friday, June 5, 2015 8:37 AM To: users@cloudstack.apache.org Cc: d...@cloudstack.apache.org Subject: Re: database high availability question vs haproxy Thanks Simon - that is what I thought... So my question would be then, haproxy vs native ACS/mysql connector going to galera1/galera2/etc...will figure out, for now we use haproxy for mysql/galera loadbalancing... THanks a lot Simon, Andrija On 5 June 2015 at 15:18, Simon Weller swel...@ena.com wrote: Personally, I think that Gallera is always going to be a safer option, as it handles conflict resolution natively. Having said that, it appears care has been taken in designing the ACS MGMT DB integration so that the chance of conflicts is very low. Galera requires a 3 nodes minimum, so it's a lot of hardware unless you've got plans to use it elsewhere in your organisation. The downside to Galera, is that it's synchronous replication, so it needs very low latency between nodes. That doesn't make it a good candidate for geographic separation between DB nodes for a DR scenario. You're understanding of the replication structure, as based on the design document is correct. MySQL (or Galera) handles all the replication. ACS just handles which node it's writing and reading from. In a 2 node native MySQL cluster, it's expected that you are setup for cross master-master replication. - Si From: Andrija Panic andrija.pa...@gmail.com Sent: Friday, June 5, 2015 2:41 AM To: d...@cloudstack.apache.org Cc: users@cloudstack.apache.org Subject: Re: database high availability question vs haproxy Hi Simon, thanks for the link - actually I have already read this - but Im still seaking for some answeres :) : - real world experience with DB HA in general - is i better to use haproxy(clustered/redudant) for mysql towards Galera cluster - or simply to reference 2 nodes (1 as master, another as slave) with native ACS DB HA - silly question but anyway... - my understanding - ACS just pings and connects to master or slave (all replication etc, is done from my side, not from ACS) ? Thanks again and any info is greatly appreciated. Andrija On 4 June 2015 at 16:23, Simon Weller swel...@ena.com wrote: Andrija, Here is the original design document, and it should give you a better idea of what is implemented today: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=34838207 We have plans to test this in our lab soon, but just haven't got around to it yet. - Si From: Andrija Panic andrija.pa...@gmail.com Sent: Thursday, June 4, 2015 9:08 AM To: d...@cloudstack.apache.org; users@cloudstack.apache.org Subject: Re: database high availability question vs haproxy Anyone :) ? On 31 May 2015 at 00:26, Andrija Panic andrija.pa...@gmail.com wrote: Hi, I would have a question on database HA feature in db.properties ( http://cloudstack-administration.readthedocs.org/en/latest/reliability.html#configuring-database-high-availability ) If I understand correctly, it is up to the admin to provide appropriate mysql HA (active-active, galera, etc) and ACS management server will JUST try to connect to slaves if the master is down ? We are running Galera, with haproxy/keepalived, and by using stoping haproxy, it takes i.e. 6sec for keepalived to detect haproxy is down, and failover IP to another host. During these 6 seconds, ACS managemnt server goes dead, because of this DB unavailability. So my wondering, is better to use ACS db HA feature, instead of loadbalancer for this specific purpose ? (we are also using haproxy/keepalived for management server loadbalancing - 2 servers in backend...) Any experience shared
Re: Strange bug? spam in management log files...
Hi, any hint on how to proceed ? on haproxy I see rougly 50%/50% sessions across 2 backend servers. But inside DB, it all points to the one mgmt_server_ip... Thanks, Andrija On 4 June 2015 at 19:27, Andrija Panic andrija.pa...@gmail.com wrote: And if of any help another hint: while Im having this lines sent to logs in high volume...if I stop second mgmt server, first one (that is making all these lines, doesnt stop to make them), so log is still heavily writen to - only when I also restart mgmt on 1st node (2nd node is down), then these log lines dissapear. Thx On 4 June 2015 at 19:19, Andrija Panic andrija.pa...@gmail.com wrote: And I could add - these lines (in this volume) only appears on first mgmt server (Actually I have 2 separate, but identical ACS installations, and same behaviour). On 4 June 2015 at 19:18, Andrija Panic andrija.pa...@gmail.com wrote: Just checked, in the HOSTS table, all agents are connected (via haproxy) to the first mgmt server...I just restarted haproxy, and still inside the DB, it says same mgmt_server_id for all agents - which is not really true. Actually, on the haproxy itslef (statistics page) I can see almoust 50%-50% distribution across 2 backends - which means by haproxy it should be fine. total 18 agents, 10 goes to 1 backend, 8 goes to other backend (ACS mgmt server) This is our haproxy config, I think it's fine, but... DB says differently, althouh haproxy statistick say all fine ### ACS 8250 ### frontend front_ACS_8250 10.20.10.100:8250 option tcplog mode tcp default_backend back_8250 backend back_8250 mode tcp balance source server acs1_8250 10.20.10.7:8250 check port 8250 inter 2000 rise 3 fall 3 server acs2_8250 10.20.10.8:8250 check port 8250 inter 2000 rise 3 fall 3 ## Any info on how to proceed with this, since because of these lines, it makes mgmt logs almoust unreadable... :( Thanks, Andrija On 4 June 2015 at 19:00, Andrija Panic andrija.pa...@gmail.com wrote: Thanks Koushik, I will check and let you know - but 11GB log file for 10h ? I dont expect this is expected :) I understand that the message is there because of setup, just an awful lot of lines Will check thx for the help ! Andrija On 4 June 2015 at 18:53, Koushik Das koushik@citrix.com wrote: This is expected in a clustered MS setup. What is the distribution of HV hosts across these MS (check host table in db for MS id)? MS owning the HV host processes all commands for that host. Grep for the sequence numbers (for e.g. 73-7374644389819187201) in both MS logs to correlate. On 04-Jun-2015, at 8:30 PM, Andrija Panic andrija.pa...@gmail.com wrote: Hi, I have 2 ACS MGMT servers, loadbalanced properly (AFAIK), and sometimes it happens that on the first node, we have extremem number of folowing line entries in the log fie, which causes many GB log in just few hours or less: (as you can see here they are not even that frequent, but sometimes, it gets really crazy with the speed/numer logged per seconds: 2015-06-04 16:55:04,089 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-29:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,129 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-28:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,129 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-8:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,169 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-26:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,169 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-30:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,209 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-27:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,209 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-2:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,249 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-4:null) Seq 1-3297479352165335041: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,249 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-7:null) Seq 73-7374644389819187201: MgmtId 90520745449919: Resp: Routing to peer 2015-06-04 16:55:04,289 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] (AgentManager-Handler-3:null) Seq
Re: database high availability question vs haproxy
I'm not sure whether that's configurable and I haven't seen any examples out there that point to it being configurable. Having said that, there are people a lot more familiar with that than I am on the list. One option you do have for this particular failure situation, is to use monit to monitor the pid of the CS management service and if it's not running, force it to start up again. Losing a load balancer completely is very rare, so it's not likely to happen often at all. - Si From: Andrija Panic andrija.pa...@gmail.com Sent: Friday, June 5, 2015 9:07 AM To: users@cloudstack.apache.org Cc: d...@cloudstack.apache.org Subject: Re: database high availability question vs haproxy Exactly...thanks Simon for the time and help :) Is there any mysql timeout/retry parameter that is set in db.properties (like db.cloud.queriesBeforeRetryMaster=5000), but I'm wondering since I'm using keepalived/haproxy setup, it takes up to 5-6 sec for keepalive to detect haproxy is down (while testing I shutdown haproxu on active node), and then keepalvied moves IP to another node - meaning I have 5-6sec of no connection between ACS mgmt servers and database/haproxy. Is this timeout configurabile on ACS/mysql connector side ? Thanks again, Andrija On 5 June 2015 at 15:54, Simon Weller swel...@ena.com wrote: I think haproxy is a better design in my opinion. You're going to have to use haproxy to balance the host agents to multiple management servers anyway, so you'll already be using it. haproxy can then manage the health checks to Galera rather than over complicating it with the CS Management configuration. - Si From: Andrija Panic andrija.pa...@gmail.com Sent: Friday, June 5, 2015 8:37 AM To: users@cloudstack.apache.org Cc: d...@cloudstack.apache.org Subject: Re: database high availability question vs haproxy Thanks Simon - that is what I thought... So my question would be then, haproxy vs native ACS/mysql connector going to galera1/galera2/etc...will figure out, for now we use haproxy for mysql/galera loadbalancing... THanks a lot Simon, Andrija On 5 June 2015 at 15:18, Simon Weller swel...@ena.com wrote: Personally, I think that Gallera is always going to be a safer option, as it handles conflict resolution natively. Having said that, it appears care has been taken in designing the ACS MGMT DB integration so that the chance of conflicts is very low. Galera requires a 3 nodes minimum, so it's a lot of hardware unless you've got plans to use it elsewhere in your organisation. The downside to Galera, is that it's synchronous replication, so it needs very low latency between nodes. That doesn't make it a good candidate for geographic separation between DB nodes for a DR scenario. You're understanding of the replication structure, as based on the design document is correct. MySQL (or Galera) handles all the replication. ACS just handles which node it's writing and reading from. In a 2 node native MySQL cluster, it's expected that you are setup for cross master-master replication. - Si From: Andrija Panic andrija.pa...@gmail.com Sent: Friday, June 5, 2015 2:41 AM To: d...@cloudstack.apache.org Cc: users@cloudstack.apache.org Subject: Re: database high availability question vs haproxy Hi Simon, thanks for the link - actually I have already read this - but Im still seaking for some answeres :) : - real world experience with DB HA in general - is i better to use haproxy(clustered/redudant) for mysql towards Galera cluster - or simply to reference 2 nodes (1 as master, another as slave) with native ACS DB HA - silly question but anyway... - my understanding - ACS just pings and connects to master or slave (all replication etc, is done from my side, not from ACS) ? Thanks again and any info is greatly appreciated. Andrija On 4 June 2015 at 16:23, Simon Weller swel...@ena.com wrote: Andrija, Here is the original design document, and it should give you a better idea of what is implemented today: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=34838207 We have plans to test this in our lab soon, but just haven't got around to it yet. - Si From: Andrija Panic andrija.pa...@gmail.com Sent: Thursday, June 4, 2015 9:08 AM To: d...@cloudstack.apache.org; users@cloudstack.apache.org Subject: Re: database high availability question vs haproxy Anyone :) ? On 31 May 2015 at 00:26, Andrija Panic andrija.pa...@gmail.com wrote: Hi, I would have a question on database HA feature in db.properties ( http://cloudstack-administration.readthedocs.org/en/latest/reliability.html#configuring-database-high-availability ) If I understand correctly,
Re: database high availability question vs haproxy
I think haproxy is a better design in my opinion. You're going to have to use haproxy to balance the host agents to multiple management servers anyway, so you'll already be using it. haproxy can then manage the health checks to Galera rather than over complicating it with the CS Management configuration. - Si From: Andrija Panic andrija.pa...@gmail.com Sent: Friday, June 5, 2015 8:37 AM To: users@cloudstack.apache.org Cc: d...@cloudstack.apache.org Subject: Re: database high availability question vs haproxy Thanks Simon - that is what I thought... So my question would be then, haproxy vs native ACS/mysql connector going to galera1/galera2/etc...will figure out, for now we use haproxy for mysql/galera loadbalancing... THanks a lot Simon, Andrija On 5 June 2015 at 15:18, Simon Weller swel...@ena.com wrote: Personally, I think that Gallera is always going to be a safer option, as it handles conflict resolution natively. Having said that, it appears care has been taken in designing the ACS MGMT DB integration so that the chance of conflicts is very low. Galera requires a 3 nodes minimum, so it's a lot of hardware unless you've got plans to use it elsewhere in your organisation. The downside to Galera, is that it's synchronous replication, so it needs very low latency between nodes. That doesn't make it a good candidate for geographic separation between DB nodes for a DR scenario. You're understanding of the replication structure, as based on the design document is correct. MySQL (or Galera) handles all the replication. ACS just handles which node it's writing and reading from. In a 2 node native MySQL cluster, it's expected that you are setup for cross master-master replication. - Si From: Andrija Panic andrija.pa...@gmail.com Sent: Friday, June 5, 2015 2:41 AM To: d...@cloudstack.apache.org Cc: users@cloudstack.apache.org Subject: Re: database high availability question vs haproxy Hi Simon, thanks for the link - actually I have already read this - but Im still seaking for some answeres :) : - real world experience with DB HA in general - is i better to use haproxy(clustered/redudant) for mysql towards Galera cluster - or simply to reference 2 nodes (1 as master, another as slave) with native ACS DB HA - silly question but anyway... - my understanding - ACS just pings and connects to master or slave (all replication etc, is done from my side, not from ACS) ? Thanks again and any info is greatly appreciated. Andrija On 4 June 2015 at 16:23, Simon Weller swel...@ena.com wrote: Andrija, Here is the original design document, and it should give you a better idea of what is implemented today: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=34838207 We have plans to test this in our lab soon, but just haven't got around to it yet. - Si From: Andrija Panic andrija.pa...@gmail.com Sent: Thursday, June 4, 2015 9:08 AM To: d...@cloudstack.apache.org; users@cloudstack.apache.org Subject: Re: database high availability question vs haproxy Anyone :) ? On 31 May 2015 at 00:26, Andrija Panic andrija.pa...@gmail.com wrote: Hi, I would have a question on database HA feature in db.properties ( http://cloudstack-administration.readthedocs.org/en/latest/reliability.html#configuring-database-high-availability ) If I understand correctly, it is up to the admin to provide appropriate mysql HA (active-active, galera, etc) and ACS management server will JUST try to connect to slaves if the master is down ? We are running Galera, with haproxy/keepalived, and by using stoping haproxy, it takes i.e. 6sec for keepalived to detect haproxy is down, and failover IP to another host. During these 6 seconds, ACS managemnt server goes dead, because of this DB unavailability. So my wondering, is better to use ACS db HA feature, instead of loadbalancer for this specific purpose ? (we are also using haproxy/keepalived for management server loadbalancing - 2 servers in backend...) Any experience shared is really appreciated ! -- Andrija Panić -- Andrija Panić -- Andrija Panić -- Andrija Panić
Re: database high availability question vs haproxy
True..Thanks Simon... On 5 June 2015 at 16:28, Simon Weller swel...@ena.com wrote: I'm not sure whether that's configurable and I haven't seen any examples out there that point to it being configurable. Having said that, there are people a lot more familiar with that than I am on the list. One option you do have for this particular failure situation, is to use monit to monitor the pid of the CS management service and if it's not running, force it to start up again. Losing a load balancer completely is very rare, so it's not likely to happen often at all. - Si From: Andrija Panic andrija.pa...@gmail.com Sent: Friday, June 5, 2015 9:07 AM To: users@cloudstack.apache.org Cc: d...@cloudstack.apache.org Subject: Re: database high availability question vs haproxy Exactly...thanks Simon for the time and help :) Is there any mysql timeout/retry parameter that is set in db.properties (like db.cloud.queriesBeforeRetryMaster=5000), but I'm wondering since I'm using keepalived/haproxy setup, it takes up to 5-6 sec for keepalive to detect haproxy is down (while testing I shutdown haproxu on active node), and then keepalvied moves IP to another node - meaning I have 5-6sec of no connection between ACS mgmt servers and database/haproxy. Is this timeout configurabile on ACS/mysql connector side ? Thanks again, Andrija On 5 June 2015 at 15:54, Simon Weller swel...@ena.com wrote: I think haproxy is a better design in my opinion. You're going to have to use haproxy to balance the host agents to multiple management servers anyway, so you'll already be using it. haproxy can then manage the health checks to Galera rather than over complicating it with the CS Management configuration. - Si From: Andrija Panic andrija.pa...@gmail.com Sent: Friday, June 5, 2015 8:37 AM To: users@cloudstack.apache.org Cc: d...@cloudstack.apache.org Subject: Re: database high availability question vs haproxy Thanks Simon - that is what I thought... So my question would be then, haproxy vs native ACS/mysql connector going to galera1/galera2/etc...will figure out, for now we use haproxy for mysql/galera loadbalancing... THanks a lot Simon, Andrija On 5 June 2015 at 15:18, Simon Weller swel...@ena.com wrote: Personally, I think that Gallera is always going to be a safer option, as it handles conflict resolution natively. Having said that, it appears care has been taken in designing the ACS MGMT DB integration so that the chance of conflicts is very low. Galera requires a 3 nodes minimum, so it's a lot of hardware unless you've got plans to use it elsewhere in your organisation. The downside to Galera, is that it's synchronous replication, so it needs very low latency between nodes. That doesn't make it a good candidate for geographic separation between DB nodes for a DR scenario. You're understanding of the replication structure, as based on the design document is correct. MySQL (or Galera) handles all the replication. ACS just handles which node it's writing and reading from. In a 2 node native MySQL cluster, it's expected that you are setup for cross master-master replication. - Si From: Andrija Panic andrija.pa...@gmail.com Sent: Friday, June 5, 2015 2:41 AM To: d...@cloudstack.apache.org Cc: users@cloudstack.apache.org Subject: Re: database high availability question vs haproxy Hi Simon, thanks for the link - actually I have already read this - but Im still seaking for some answeres :) : - real world experience with DB HA in general - is i better to use haproxy(clustered/redudant) for mysql towards Galera cluster - or simply to reference 2 nodes (1 as master, another as slave) with native ACS DB HA - silly question but anyway... - my understanding - ACS just pings and connects to master or slave (all replication etc, is done from my side, not from ACS) ? Thanks again and any info is greatly appreciated. Andrija On 4 June 2015 at 16:23, Simon Weller swel...@ena.com wrote: Andrija, Here is the original design document, and it should give you a better idea of what is implemented today: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=34838207 We have plans to test this in our lab soon, but just haven't got around to it yet. - Si From: Andrija Panic andrija.pa...@gmail.com Sent: Thursday, June 4, 2015 9:08 AM To: d...@cloudstack.apache.org; users@cloudstack.apache.org Subject: Re: database high availability question vs haproxy Anyone :) ? On 31 May 2015 at 00:26, Andrija Panic andrija.pa...@gmail.com wrote: Hi, I would
Re: 4.3 - 4.5 breaks networking
On 2015-06-04 00:37, Sanjeev N wrote: If VR and VM on the same host works fine, then some vlan configuration is missing on the switch connecting both the hosts. Make sure you have configured the switch ports as tagged and allow all the vlans being used for guest and public networks. Everything was working under 4.3 and I've been able to manually setup vlan's and transmit data between hosts. On 2015-06-03 21:08, ilya wrote: Mike We are missing context of your lab setup. Perhaps TCP dump can help with debugging? I'll see if I can grab a TCP dump soon. I've included my overall config below if it might help. === = Zone Network/VLAN Setup === Physical Network CloudStack Public: vlan, ip ranges in 172.16.17.0/24 and vlan://untagged ; cloudbr0 as adapter Guest: ip range 172.16.18.0/24 and vlans 1201 - 1225 ; cloudbr1 as adapter Management ip's in range 172.16.16.0/24 mgmtbr0 as adapter === = Source network cconfig === Management: mgmbr0 - eth0 - multiple ip's specified, each in 172.16.16.0/24 range cloudbr0: bond0.1100 - p1p1 p1p2 - no ip address specified cloudbr1: bond0.1200 - p1p1 p1p2 - no ip address specified bond0: mode balance-alb - no ip address specified === = Destination network config === Management: mgmtbr0 - eth1 - one ip specified in 172.16.16.0/24 range cloudbr0: eth0.1100 - no ip address specified cloudbr1: eth0.1200 - no ip address specified
How do I contribute to ACS documentation?
Hi, All, I am Rajsekhar Kunnampally, working with Citrix CloudPlatform documentation team. I am working from Citrix, Bangalore. I have been associated with the CloudPlatform documentation team for the past one year. My focus was on revamping the CloudPlatform documentation set and creating content for new releases, hotfixes, and patches. I would like to contribute to the ACS documentation too. I think I can start by creating documentation to complement the contributions from the CloudPlatform engineers. However, I would like to understand the tools and the processes that ACS documentation uses. Also, I have a few questions that I would like to clarify before I start contributing to ACS documentation. Who can I contact for guidance? Thanks in advance for your help. Regards, Rajsekhar
How to shutdown whole CloudStack
Hi all, Im on CS 4.4.2 with ESXi 5.5. Theres gonna be a maintenance of the physical servers. The question is: how do I proper shut down entire CS Infra? without having problems when I power on it again. Regards, José
Re: storage migration of vm on local storage
You should be able to use cloudstack to move a VM from Local Storage to shared storage. but you might need to unmount the data disk and perform this task with the VM as shutdown as the Migrate Instance button will allow you to specify the Storage. Regards, On Wed, Jun 3, 2015 at 9:18 PM, Ahmad Emneina aemne...@gmail.com wrote: I believe you can use storage XenMotion[0] for that. Not sure it can be done from within cloudstack, but should be achievable. [0] http://wiki.xen.org/wiki/Storage_XenMotion 2015-05-29 9:36 GMT-07:00 S. Brüseke - proIO GmbH s.brues...@proio.com: Hi, documentation is a little bit confusing about this. Is it possible in CS 4.3 (XenServer 6.2 SP! as hypervisor) to migrate a vm if this vm is on local storage without to stop the vm? Mit freundlichen Grüßen / With kind regards, Swen Brüseke - proIO GmbH - Geschäftsführer: Swen Brüseke Sitz der Gesellschaft: Frankfurt am Main USt-IdNr. DE 267 075 918 Registergericht: Frankfurt am Main - HRB 86239 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
