Software Defined Networking (SDN) & Software Defined Storage (SDS)

Software Defined Networking (SDN) & Software Defined Storage (SDS) KARL WITTHUHN CSCI 5980 DAVID DU

Overview Traditional Network Design Traditional Network Diagram Software Defined Network (SDN) Design SDN Network Diagrams Why SDN? Traditional NAS/SAN Design Software Defined Storage Design Why SDS? SDN/SDS Products & Software Conclusion

Traditional Networking Design Control Plane and Data Plane exist on every device in the network Control plane responsible for configuration and management of network such as routing protocols, access control lists (ACLs), remote management Data plane responsible for forwarding, dropping, rate-limiting, filtering data packets to next destination Each device has individual firmware, configurations, and capacity Routing databases and full network connectivity can take time to propagate to all devices Example – a link goes down 5 network hops away – a device will have to update a neighbor – which then updates the next neighbor and so on

R1 Traditional Network Diagram R2 O E2 10.0.1.0/24 [110/1] via 192.168.1.1, Fa0/0 O E2 10.0.2.0/24 [110/1] via 172.16.1.1, Fa0/1 C 192.168.1.0/30 is directly connected, Fa0/0 Fa0/0 C 172.16.1.0/30 is directly connected, 172.16.1.1/30 L192.168.1.1/30 Fa0/1 in O E2 10.0.1.0/24 [110/1] via 192.168.1.2, Fa0/0 O E2 172.16.1.0/30 [110/1] via 192.168.1.2, Fa0/0 C 192.168.1.0/30 is directly connected, Fa0/0 OSPF Values Default Fa0/0 C 10.0.2.0/24 is directly connected, Fa0/1 hello-timer: 10s dead-timer: 40s Fa0/1 10.0.2.1/24 R1 kS tat eU pd a te (L S R3 O E2 10.0.2.0/24 [110/1] via 172.16.1.2, Fa0/0 O E2 192.168.1.0/30 [110/1] via 172.16.1.2, Fa0/0 C 172.16.1.0/30 is directly connected, Fa0/0 C 10.0.1.0/24 is directly connected, Fa0/1 R3 Fa0/1 10.0.1.1/24 A R2 Fa0/0 ) 192.168.1.2/30 Fa0/1 172.16.1.2/30 OSPF Hello #1 (10s) OSPF Hello #2 (20s) 10.0.2.0/24 OSPF Hello #3 (30s) OSPF Hello #4 (40s) R3 Dead R2 Update Table 10.0.1.0/24

Software Defined Networking (SDN) Design Most important item to remember – SDN centralizes the control plane into one place – an SDN controller Data packets moving on the network defined as “Data Flows” Networking hardware such as routers, switches, & firewalls can be generic and diverse Hardware must support SDN module compatible with SDN controller Controller communicates to hardware via a southbound API Controller has a series of logical match tables called “Flow Tables” Upper layer applications can define networking requirements to an SDN controller SDN controller programs data planes to achieve requirements

SDN Design (Cont.) Flow Tables Classification are statements that define a match pattern against packets Src/Dst IP, MAC, TCP/UDP port, Protocol, QoS classification, etc. Action – how to process a matched packet Basic Actions: Drop, Forward, Set Newer actions: Push/Pop (Labels), Copy-in/out (TTL), Increment/Decrement Default no match results in an explicit DROP action Statistics on all actions are counted – this can be used for data evaluation, monitoring, or even adaptable decisions such as hot/cold ports Flow Table 1 Match 1 Match 1 Forward Match 2 Match 2 Forward Data IN Flow Table 0 Forward Match 3 Drop Match 1 Go to Flow table 1 Match 2 Go to Flow table 2 Flow Table 2 Match 3 Drop Match 1 Forward Match 2 Forward Match 3 Drop

SDN Network Diagram Out-of-Band Network IT ERM - P TCH 1 MA SDN Controller Public Src: 1.1.1.1 Dst: 10.0.1.1 R1 - P H ATC M 1 IT ERM 1 C T A M H - P ER R2 10.0.2.0/24 10.0.1.0/24 IT M R3 Ingress Policy 1 DST: 10.0.1.0/24 2 DST: 10.0.2.0/24 3 Default Action: Permit Action: Drop Action: Drop

SDN Network Diagram Out-of-Band Network SDN Controller Public Src: 1.1.1.1 Dst: 10.0.2.1 2M H - C T A P D RO R1 Ingress Policy 1 DST: 10.0.1.0/24 2 DST: 10.0.2.0/24 3 Default R3 R2 10.0.2.0/24 10.0.1.0/24 Action: Permit Action: Drop Action: Drop

Why SDN? Traditional design does not scale Maintenance of multitude of devices, configurations, and firmware becomes untenable Myriad options for vendors, each with multiple networking operating systems, CLI, & GUI Once developed, SDN can provide single window into security, configuration, and packet actions Easier to add or remove capacity on the fly Possible to add more routers or switches without taking down network for maintenance windows Rules can be instantly applied to new equipment as soon as it can communicate to the SDN controller

Traditional NAS/SAN Storage Design Vendor specific applications and software Designing a custom storage solution can be extremely expensive Solutions are created to meet a specific need or requirement For example, a company might need 100 TB of NFS-mountable storage This approach might be difficult to adapt to a future storage need Devices/Applications might have different operating systems, configurations, firmware revisions, etc. Occasionally protocol conversion required – such as Infiniband over IP (IPoIB) to take data from one area and write to a storage application Overhead can cause performance loss Difficult to troubleshoot specific use-cases with low adoption

Software Defined Storage (SDS) Design Main point like networking is SDS abstracts the software layer from the physical hardware Spawned from the trend of hyperconverged infrastructure (softwaredefined . insert technology here ) Like SDN, uses an SDS controller to handle generic storage functions Uses standard API across all hardware to accomplish storage functions such as write, read, etc. SDS still requires an intentional task to architect solutions around storage capabilities (IOPS, Lifespan, Capacity, etc.) Monitoring is still a challenge – catching errors and hardware degradation needs to be considered, even though redundancy is built into SDS

Why SDS? Adding new types of storage devices is easy abstraction of write/read operations allows for mixture of functionalities within a single storage solution Scalability is functionally limitless No SAN/NAS appliance specific limits on number of devices to manage No vendor CLI/GUI lock-in Hardware can be sourced from a variety of diverse manufacturers Like SDN, add/remote storage devices without downtime Adapt to unknown and future workloads without having to create a new storage implementation SDS can easily adapt to high write/low read or low write/high read workloads without changing underlying hardware

SDN Protocols and Software Open-Source OpenDaylight (ODL) Project Floodlight (based on Java) NOX/POX Open vSwitch Vendor/Commercial Juniper Contrail Cisco ACI NXP VortiQA VMWare NSX

SDS Protocols and Software CephFS GlusterFS Object store running on top of native file systems Distributed File store generally supporting overlay file systems Other SDS Concepts and Products Exist MooseFS HDFS DRDB

Challenges & Conclusion Early adoptions of SDN protocols had scenarios where control plane was showing correct flow tables, yet measurement of data plane forwarding did not match SDS/SDN solutions can be challenging to migrate existing storage/networking over to new implementation Slow switch CPUs, time to update switch ASICs, packet loss all contributing factors to issue Staff education, unsupported legacy hardware, under performing hardware Most companies are investing lots of resources into simplifying an evergrowing demand for storage and networking requirements By 2025, IDC says worldwide data will grow 61% to 175 zettabytes, with as much of the data residing in the cloud as in data centers. [6] That’s 175,000,000,000,000 Gigabytes!

Sources [1] Ceph vs GlusterFS vs MooseFS vs HDFS vs DRBD [2] SDN Versus Traditional Networking Explained https://zadara.com/blog/2016/04/06/differences-software-defined-stor age-traditional-san-nas-cloud-storage-2/ [4] What You Need to Know About SDN Flow Tables https://www.ibm.com/services/network/sdn-versus-traditional-networ king [3] What are the Differences Between Software-Defined Storage and Traditional SAN & NAS? https://computingforgeeks.com/ceph-vs-glusterfs-vs-moosefs-vs-hdfsvs-drbd/ https://people.kth.se/ dejanko/documents/publications/switches-pam 15.pdf [5] OpenFlow Instructions & Actions http://flowgrammable.org/sdn/openflow/actions/#tab ofp 1 4

Sources (Cont.) [6] IDC: Expect 175 zettabytes of data worldwide by 2025 https://www.networkworld.com/article/3325397/idc-expect-175-zetta bytes-of-data-worldwide-by-2025.html

Thank You!