Thanks to Kevin’s explanation. Some more comment on Tricircle. Hybrid cloud is only one of the use cases, there are two other use cases for Tricircle:
1. massive distributed edge clouds Current Internet is good at processing downlink service. All contents are stored in centralized data centers and to some extent the access is accelerated with CDN. As more and more user generated content uploaded to the cloud and web site, these contents and data still have to be uploaded to some big data centers, the path is long and the bandwidth is limited and slow. For example, it’s very slow to upload/streaming HD/2k/4k video for every user concurrently, both for pictures or videos, they have to be uploaded with quality loss, and slow, use cloud as the first storage for user data is not the choice yet, currently it’s mainly for backup, and for non- time sensitive data. Some video captured and stored with quality loss even lead to the difficulty to provide the crime evidence or other purpose. The last mile of network access (fix or mobile) is wide enough, the main hindrance is that bandwidth in MAN(Metropolitan Area Network) and Backbone and WAN is limited and expensive. Now building the massive distributed edge clouds in edge data centers (compared to the centralized cloud) with computing and storage close to end user is emerging, and even for NFV with more flexible networking capability will provide better personalized networking functionalities, and also help to move the computation and storage close to end user. With shortest path from the end user to the storage and computation, the uplink speed could be larger and terminate the bandwidth consumption as early as possible, will definitely bring better user experience, and change the way of content generation and store: real time, all data in cloud. VNF/App/Storage in the edge cloud can provide better user experience for the end user, the movement or distribution of VNF/App/Storage from one edge data center to another one is also needed. For example, all video will be stored and processed in Hawaii locally when I am taking video in travelling, but I hope the video after processing will be moved to China Shenzhen when I come back to China. But in Shenzhen, I want to share the video with streaming service not only in Shenzhen but to friends in Shanghai Beijing, so the data and the streaming service can be built in Shenzhen/Shanghai/Beijing too. For VNF, distributed designed VNF will be placed to multiple edge data centers for higher reliability/availability, and even chaining multiple VNFs cross edge data centers for better customized networking capabilities. The emerging massive distributed edge clouds will not only be some independent clouds, some new requirements are needed: n Tenant level L2/L3 networking across data centers n Volume/VM/object storage migration/distribution n Distributed image management n Distributed quota management n ... This is the job of Tricircle to work as OpenStack API gateway to the edge clouds, and address the functionalities cross edge site cloud. 2. large scale cloud Compared Amazon, the scalability of OpenStack is still not good enough. One Amazon AZ can supports >50000 servers(http://www.slideshare.net/AmazonWebServices/spot301-aws-innovation-at-scale-aws-reinvent-2014). Cells is a good enhancement, but the shortage of Cells is: 1) only nova supports cells. 2) using RPC for inter-datacenter communication will bring the difficulty in inter-dc troubleshooting. 3) upgrade has to deal with DB and RPC change. 4)difficult for multi-vendor integration for different cell. From the experience of production large scale public cloud, the large scale cloud can only be built by capacity expansion step by step (intra-AZ and inter-AZ). And the challenge in capacity expansion is how to do the sizing: n Number of Nova-API Server... n Number of Cinder-API Server.. n Number of Neutron-API Server… n Number of Scheduler.. n Number of Conductor… n specification of physical server… n specification of physical switch… n Size of storage for Image.. n Size of management plane bandwidth… n size of data plane bandwidth… n reservation of rack space … n reservation of networking slots… n …. You have to estimate, calculate, monitoring, simulate, test, online grey expansion for controller nodes and network nodes…whenever you add new machines to the cloud. The difficulty is that you can’t test and verify in all size, not to mention >50000 servers. The feasible way to expand one large scale cloud is to add some already tested building block, that means we would prefer to build large scale public cloud by adding tested OpenStack instance (including controller and compute nodes) one by one, but not enlarge one OpenStack uncontraintly. This way put the cloud construction under control. Building large scale cloud by adding tested OpenStack instance one by one, will lead to tenant’s resource distributed in multiple OpenStacks, also brings some new requirement to OpenStack based cloud, quite similar like that in massive distributed edge clouds: ● Tenant level L2/L3 networking across OpenStack instances ● Distributed quota management ● Global resource view of the tenant ● Image distribution management ● Volume/VM migration ● ... This is the job of Tricircle to work as OpenStack API gateway to the multiple OpenStack instances in one AZ or multiple AZs, and address the functionalities cross OpenStack instance. For how Tricircle to deal with these use cases in more detail, please refer to the slides: https://docs.google.com/presentation/d/1UQWeAMIJgJsWw-cyz9R7NvcAuSWUnKvaZFXLfRAQ6fI/ Best Regards Chaoyi Huang ( Joe Huang ) From: Kevin.ZhangSen [mailto:[email protected]] Sent: Sunday, March 20, 2016 11:42 AM To: [email protected] Subject: [openstack-dev] [new-project][jacket] Introduction to jacket, a new project Hi all, There is a new project "Jacket" to unify the API models of different clouds using OpenStack API. Its wiki is: https://wiki.openstack.org/wiki/Jacket After the discussion of last week, I update the description in wiki about the relations between Jacket and Tricircle, and add the "FAQ" section. Please review and give your suggestions, thanks. Thanks again for the good suggestions and support from Gordon Chung, Janki Chhatbar, Shinobu Kinjo, Joe Huang and Phuong. Best Regars, Kevin (Sen Zhang) Q: Is Jacket one kind of API gateway for different clouds? Jacket isn't an API gateway for different clouds. The aim of Jacket is to offer the unified OpenStack API model for different clouds, so the major task of Jacket is to shield the differences between provider cloud and OpenStack through the sub services in Jacket such as “Unified resource uuid allocation”， "Fake volume management" and so on. Q: What is the relation between Tricircle and Jacket? Jacket focuses on how to unify the API models of clouds using OpenStack API model, and how to use one OpenStack instance to manage one provider cloud. Tricircle focuses on how to manage multiply OpenStack instances and networking automation across multiple OpenStack instances. So it is a good solution to use Tricircle to manage multiply different clouds at the same time, each one of which is managed by OpenStack instance through Jacket.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
