Adam, fuel does support multiple PXE networks via the nodegroup/multiple clusters feature, however in the geo-diverse case this would receive limited use as it's mostly useful for a spine and leaf network topology. As you noted, in the geo-diverse case you would typically deploy an env for the keystone / glance cluster and then separate env's (most like with different fuel nodes) you would deploy the individual regions.
On Wed, Oct 7, 2015 at 3:28 AM Adam Heczko <ahec...@mirantis.com> wrote: > Hi, although I'm not participating in this story since very beginning, let > me add my 2 cents. > For scalability purposes Nova considers rather use of 'cells' rather than > 'regions' construct. > Regions as name suggests deals with geographically dispersed data centre > locations. > In regards to Fuel architecture, since Fuel supports only one PXE network, > it is IMO unable to deploy multi region clouds. > Fuel uses 'environments' construct, but again it doesn't fit to 'region' > nor 'cell', since Fuel's 'environment' deploys just another cluster (with > own set of controllers, computes etc.) over the shared PXE network. > It is probably quite affordable to add 'cells' capability to Fuel, maybe > through Fuel-plugins mechanism, which could decouple nova-scheduler and > related roles from 'main' controller role. > For true multi-region capability, it would be required to operate > multi-cobbler Fuel instances / multiple PXE networks with appropriate > 'region' names provided. > A initial approach to it would be probably to deploy multiple Fuel > instances (one Fuel per region) and then bound them altogether through > RESTful API / operate at scale through API, at least when it comes to > Keystone and Galera cluster configuration. > There are several approaches to multi region, maybe good one would be > plugin allowing to select remote data centre Galera cluster as a partner > for replication. > I'm not sure at this moment how HA would be operated this way, since > Keystone utilizes memcached for various operations. Would multi-region > memcached memory states also be synchronized? > So multi-region DC could rise up a lot related to it problems. > > Regards, > > A. > > > > On Wed, Oct 7, 2015 at 11:49 AM, Roman Sokolkov <rsokol...@mirantis.com> > wrote: > >> Sheena, thanks. I agree with Chris full Multi-DC it's different scale >> task. >> >> For now Services just need +1 tiny step from Fuel/Product in favor >> supporting current Multi-DC deployments architectures. (i.e. shared >> Keystone) >> >> Andrew, Ruslan, Mike, >> >> i've created tiny blueprint >> https://blueprints.launchpad.net/fuel/+spec/expose-region-name-to-ui >> >> We just need to expose already existing functionality to UI. >> >> Can someone pickup this blueprint? And/Or reassign to appropriate team. >> >> Thanks >> >> On Fri, Oct 2, 2015 at 7:41 PM, Sheena Gregson <sgreg...@mirantis.com> >> wrote: >> >>> Forwarding since Chris isn’t subscribed. >>> >>> >>> >>> *From:* Chris Clason [mailto:ccla...@mirantis.com] >>> *Sent:* Friday, October 02, 2015 6:30 PM >>> *To:* Sheena Gregson <sgreg...@mirantis.com>; OpenStack Development >>> Mailing List (not for usage questions) < >>> openstack-dev@lists.openstack.org> >>> *Subject:* Re: [openstack-dev] [Fuel] 8.0 Region name support / Multi-DC >>> >>> >>> >>> We are doing some technology evaluations with the intent of publishing >>> reference architectures at various scale points (500, 1500, 2000 etc). Part >>> of this work will be to determine how to best partition the nodes in to >>> regions based on scale limits of OpenStack components and workload >>> characteristics. The work we are doing increased in scope significantly, so >>> the first RA will be coming at the end of Q1 or early Q2. >>> >>> >>> >>> We do plan on using some components of Fuel for our testing but the main >>> purpose is path finding. The work we do will eventually make it into Fuel, >>> but we are going to run in front of it a bit. >>> >>> >>> >>> On Fri, Oct 2, 2015 at 9:19 AM Sheena Gregson <sgreg...@mirantis.com> >>> wrote: >>> >>> Plans for multi-DC: my understanding is that we are working on >>> developing a whitepaper in Q4 that will provide a possible OpenStack >>> multi-DC configuration, but I do not know whether or not we intend to >>> include Fuel in the scope of this work (my guess would be no). Chris – I >>> copied you in case you wanted to comment here. >>> >>> >>> >>> Regarding specifying region names in UI, is it possible to specify >>> region names in API? And (apologies for my ignorance on this one) what is >>> the relative equivalence to environments in Fuel (e.g. 1 environment : many >>> regions, 1 environment == 1 region)? >>> >>> >>> >>> *From:* Roman Sokolkov [mailto:rsokol...@mirantis.com] >>> *Sent:* Friday, October 02, 2015 5:26 PM >>> *To:* OpenStack Development Mailing List (not for usage questions) < >>> openstack-dev@lists.openstack.org> >>> *Subject:* [openstack-dev] [Fuel] 8.0 Region name support / Multi-DC >>> >>> >>> >>> Folks, >>> >>> >>> >>> i've dug around 8.0 roadmap and didn't find anythind regarding Multi-DC >>> support. >>> >>> >>> >>> My ask is about tiny(but useful) feature: give user ability to *specify >>> Region name in UI.* >>> >>> >>> >>> Region name is already in every puppet module, so we just need to add >>> this to UI. >>> >>> >>> >>> Do we have smth already? >>> >>> >>> >>> More general question: What are our plans in regards Multi-DC? >>> >>> >>> >>> Thanks >>> >>> >>> >>> -- >>> >>> Roman Sokolkov, >>> >>> Deployment Engineer, >>> >>> Mirantis, Inc. >>> Skype rsokolkov, >>> rsokol...@mirantis.com >>> >>> -- >>> >>> Chris Clason >>> >>> Director of Architecture >>> >>> ccla...@mirantis.com >>> >>> Mobile: +1.408.409.0295 >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> >> -- >> Roman Sokolkov, >> Deployment Engineer, >> Mirantis, Inc. >> Skype rsokolkov, >> rsokol...@mirantis.com >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Adam Heczko > Security Engineer @ Mirantis Inc. > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
