Selforganizing cloud (SOC) Clouds today - Modern cloud platforms are very complicated while deployment, adjustments and support (f.e. OpenStack): 2 Why SOC? Cloud platforms today: do NOT support SLA for all user resources (computational, networking, data storage) have NOT unified resource planning are NOT designed for NFV do NOT support topology of virtual tenant network SOC is designed to support all of the above 3 Why SOC? Everything is aimed to speedup return of investments (ROI) 4 NFV by design OpenStack SOC Management Network C-Node VM VNF VM VNF R-Node API Network Data Network External network Internet 5 SLA for virtual network SLA SLA SLA SLA • Tenant can describe quality for each sliver of virtual network • SOC maps it to physical network optimizing for performance • Thus virtual tenant network could be: • either: uncontrollable by tenant with guaranteed SLA • or: controllable by tenant and consisting of elements with guaranteed properties 6 Increasing utilization of resources Requests for resources Compute Networking Storage Unified planning alows to achieve up to 90% (est.) data centers’ hardware resource utilization 7 Nothing comes for granted High utilization means: fight with fragmentation or DIE! (still one has to keep SLA) The solution is: live migration of allocated objects Yet, live migration is SLOW. So one has to plan resources devoted to migration as a special tenant(s). 8 SOC development stages SOC is supposed to be developed in stages Stages are not strictly defined, development path could be modified to suit potential customers needs The final goal is set as a self organized cloud with guaranteed SLA The tracks to achieve it could be different. There are many ways to do it (TIMWTDI) Stage I (ready) Incorporating unified scheduler for nova and cinder NFV concept demo Language for description of tenants' virtual networks Graphical tools for tenants’ network description and resources control Orchestrator creation and incorporation Stage II (current) OpenFlow controller incorporation Automatic network topology mapping and changes tracking (OpenFlow driven) Link aggregation control protocol emulation and extension (OpenFlow driven) Sensors everywhere, including netrwork interfaces, tunnels Stage III Network virtualization with guaranteed SLA OpenStack Neutron module redesign NFV(VNF) full scale support Bare metal as a service, quick deployment and diagnostic tools Something else on request Features considered for implementation after stage III Rapid deployment as private cloud templates Multiple Data Centers aggregation and unified control Rapid application deployment patterns and templates (Oracle, 1C, web apps) LXC containers usage Advanced backup and storage with enchanced reliability (geodistributed) Automatic installing and maintanance Metal-as-a-service (project) Param Vol 1-st conf. servers RAM High CPU High HDD No Install from Flash drive 2-nd conf. servers PXE IPMI RAM Low CPU Low HDD Low Network Available resources Test results 1-st server Server role N-th conf. servers RAM Low CPU Low HDD High 14 SOC usage cases Supposed customers of SOC Small sized cloud-like data center with NFV support for telecom operators Private corporate cloud with network security policies support «Cloudified» datacenter for governmental facilities with increased data and network security support Conclusions SOC designed to decrease deployment and maintenance cost SOC guarantees functional networking SLA (not only networking actually) Scheduling algorithms applied in SOC will allow to achieve high hardware resource utilization SOC will allow tenant interaction inside the platform with minimal overhead according to NFV concept Thank you for attention Capabilities of proposed virtualization mechanisms Unified resources planning: computational, networking, data storage Capability to define SLA for all types of resources Uncontrollable tenant with guaranteed SLA Virtual network controllable by tenant and consisting of elements with guaranteed properties Unified planning alows to achieve up to 90% (est.) data centers’ hardware resource utilization 18 SLA for virtual network SLA SLA SLA SLA • Tenant can describe quality for each sliver of virtual network • SOC maps it to physical network optimizing for performance • Capability to define SLA for networking resources leads • either to: uncontrollable by tenant virtual network with guaranteed SLA • or to: virtual network controllable by tenant consisting of elements with guaranteed properties 19 Similar products VmWare vCloud OpenStack, especially:  MAAS/Juju от Canonical  Fuel от Mirantis PLUMgrid 20