Ok that sounds promising. Does it require 3.6 at minimum? We already handle starting vms using vdsm in case the network from hypervisors to engine is down. As well as disabling fencingmto avoid a sloppy network to try and make changes. I would like to reduce the comms between hosts and engine. Are there any ideas you would have about that.
Verstuurd vanaf mijn iPhone > Op 28 apr. 2016 om 13:55 heeft Michal Skrivanek <michal.skriva...@redhat.com> > het volgende geschreven: > > >>> On 26 Apr 2016, at 16:48, Martin Sivak <msi...@redhat.com> wrote: >>> >>> @awels: to add another layer of indirection via a dedicated >>> hosted-engine per outlet seems a little much. we are talking about 500 * >>> 4GB RAM at least in this example, so 2 TB RAM just for management >>> purposes, if you follow engine hardware recommendations? >> >> I would not go that far. Creating zones per continent (for example) >> might be enough. >> >>> At least RHEV states in the documentation you support up to 200 hosts >>> per cluster alone. >> >> The default configuration seems to only allow 250 hosts per datacenter. >> >> # engine-config -g MaxNumberOfHostsInStoragePool >> MaxNumberOfHostsInStoragePool: 250 version: general > > yep, but that liit is there because within a DC there is a lot of assumption > for flawless fast enough communication, the most problematic is that all > hosts need to access the same storage and the monitoring gets expensive then. > This is a different situation with separate DCs, there’s no cross-DC > communication. > I would guess many DCs work great actually. > > Too many hosts and VMs in total might be an issue, but since the last > official updates there were a lot of changes. E.g. in stable state due to VM > status events introduced in 3.6 the traffic required between each host and > engine is much lower. > I would not be so afraid of thousands anymore, but of course YMMV > >> >> -- >> Martin Sivak >> SLA / oVirt >> >>> On Tue, Apr 26, 2016 at 4:03 PM, Sven Kieske <svenkie...@gmail.com> wrote: >>>> On 26.04.2016 14:46, Martin Sivak wrote: >>>> I think that 1000 hosts per engine is a bit over what we recommend >>>> (and support). The fact that all of them are going to be remote might >>>> not be ideal either. The engine assumes the network connection to all >>>> hosts is almost flawless and the necessary routing and distance to >>>> your hosts might not play nice with (for example) the fencing logic. >>> >>> Hi, >>> >>> this seems a little surprising. >>> >>> At least RHEV states in the documentation you support up to 200 hosts >>> per cluster alone. >>> >>> There are no documented maxima for clusters or datacenters though. >>> >>> @awels: to add another layer of indirection via a dedicated >>> hosted-engine per outlet seems a little much. we are talking about 500 * >>> 4GB RAM at least in this example, so 2 TB RAM just for management >>> purposes, if you follow engine hardware recommendations? > > yeah. currently the added layer of manageiq with HEs everywhere is not that > helpful for this particular case. Still, a per-continent split or > per-low-latency-area might not be a bad idea. > I can imagine with a bit more tolerant timeouts and refreshes it might work > well, with incidents/disconnects being isolated within a DC > >>> >>> But I agree, ovirt does not handle unstable or remote connections that > > right. but most of that is again per-DC. You can’t do much cross-DC though > (e.g. sharing a template is a pain) > > Thanks > michal > >>> well, so you might be better of with hundredths of remote engines, but >>> it seems to be a nightmare to manage, even if you automate everything. >>> >>> My personal experience is, that ovirt does scale at least until about >>> 30-50 DCs managed by a single engine, but that setup was also on a LAN >>> (but I would say it could scale well beyond these numbers, at least on a >>> LAN). >>> >>> HTH >>> >>> Sven >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >> _______________________________________________ >> Users mailing list >> Users@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users > _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
