Datera and Modern Data Center

Datera presented at Tech Field Day 18 and provided additional insights on their software-defined storage solution as well as perspectives on modern Data Centers. Datera’s Team:

– Al Woods, CTO
– Nic Bellinger, Chief Architect and Co-Founder
– Bill Borsari, Head of Field Systems Engineering
– Shailesh Mittal, Sr. Engineering Architect

The presentation started with an introduction on enterprise software-defined storage, characteristics of a software-defined Data Center, overview of their data services platform pillars, business use cases, and current server partnerships that their software runs on.

no-silos

Datera’s meaning of a software-defined Data Center includes these characteristics:

1 – All hardware is virtualized and delivered as a service
2 – Control of the Data Center is fully automated by software
3 – Supports legacy and cloud-native applications
4 – Radically lower cost versus hard wired Data Centers

With this mind, the building blocks of the Datera Data Server Platform architecture were also presented which is extremely relevant for those interested on what is “under the hood” and how it is built, and where standard functions such as dedup, tiering, compression, and snapshots happen. Datera focused on demonstrating how the architecture is optimized to overcome the traditional storage management and data movement challenges. This is where one needs to have some background on storage operation to fully understand the evolution to a platform built for always-on transparent data movement working on a distributed, lockless, application intent driven architecture running on x86 servers. The overall solution is driven by application service level objectives (SLOs) intended to provide a “self-driving” storage infrastructure.

There were no lab demos during the sessions, however, there were some unique slide animations on what Datera calls continuous availability and perpetual storage service to contextualize how their solution works. The last part of the presentation was about containers and microservices applications and how Datera provides enough flexibility and safeguards to address such workloads and portability nature.

Modern Data Center

In a whiteboard explanation, Datera also shared that they have seen more Clos style (leaf-spine) network architecture on modern Data Centers, and see themselves as “servers” that are running in a rack-scale design alongside independent compute nodes. The network is the backplane and integral part of the technology, as compute nodes access the server-based software storage over the network with high-performance iSCSI interfaces. It also supports S3 object storage access.

One of the things I learned during the presentation is their ability to peer directly with the top of rack (leaf) switches via BGP. The list of networking vendors is published here. Essentially, Datera integrates SLO-based L3 network function virtualization (NFV) with SLO-based data virtualization to automatically provide secure and scalable data connectivity as a service for every application. It accomplishes this by running a software router (BGP) on each of its nodes as a managed service, similar to Project Calico. Al Woods wrote about the benefits of L3 networking very eloquently on this article. I find it interesting how BGP is making its way inside Data Centers in some shape or form.

In addition to the L3 networking integration for more Data Center awareness, Datera adopts an API first design by making everything API-driven, a policy-based approach from day 1 which is meant for easy operations at scale, and targeted data placement to ensure data is distributed correctly across physical infrastructure to provide for availability and resilience. This is all aligned to the concept of a scale-out modern Data Center.

As a follow-up, Datera will also be presenting at Storage Field Day 18 and there may be more opportunity to delve into their technology and have a glimpse of the user interface and multi-tenancy capabilities.

Tech Field Days

IMG_4402

… a continuation of the beginning.

I had my second appearance on Tech Field Day 18 this week, which is a major accomplishment for someone who for a long time was quiet on social media and the likes. Not that I have changed much, but it is definitely a huge step being “outside”. I had the opportunity to meet several very professional, intelligent and insightful people with great minds and an amazing ability to express themselves (in writing, speaking, improvising, podcasting). It is been an overwhelming learning experience more than anything else. Social (soft) skills do not come overnight, and it is fundamental on building trust and long-term relationships with people who naturally enlight, inspire or pave the way for others.

The video presentations have been posted for Datera, NetApp, VMware, and SolarWinds.

 

ACI Troubleshooting Notes

screenshot2019-01-31at5.43.53pm

I attended a 3-day ACI Troubleshooting v3.1 bootcamp this week and I have to say, even though I do not get involved in actual implementation after the architecture and design, it is always valuable to understand how things (can) break and ways to troubleshoot. Here are some notes I put together:

Fabric Discovery

I learned that show lldp neighbors can save lives when proposed diagram does not match physical topology. Mapping serial number to node ID and name is a must before and during fabric discovery.  The acidiag fnvread is also very helpful during the process.

Access Policies

For any endpoint connected, verification can be done top down, bottom up, or randomly, but regardless of the methodology, always make sure the policies are all interconnected. I like the top down approach, starting with switch policies (including VPC explicit groups), switch profiles, then interface policies and profile followed by policy groups. This is where all policies need to be in place (ie.: CDP, LLDP, port-channel mode) and most importantly, association to a AEP, which in turn needs to be associated to a domain (physical, VMM, L2, L3) and a VLAN pool followed by a range. If they are all interconnected, the AEP is bridging everything, then comes the logical part of the fabric.

I can only imagine what a missing AEP association can do in a real world deployment.

L2 Out

By extending a bridge domain to an external layer 2 network, a contract is required on the L2 Out (external EPG), that is known. Now, assuming this is a no-filter contract, it can be either a provider or consumer, as long as the EPG associated to the bridge domain being extended also has a matching contract, that is, if the L2 Out has a consumer contract, the associated EPG needs to have a provider contract. If L2 Out has a provider contract, then the EPG needs a consumer contract. In short, everytime I think I finally nailed the provider and consumer behavior, I learn otherwise.

L3 Out

Assuming all access policies are in place, in a OSPF connection, the same traditional checks are required, from MTU to network type. If the external device is using SVI, network broadcast is required on the OSPF interface profile for the L3 Out. I had point-to-point for a while. This is probably basics, but sometimes one can spend considerable time checking unrelated configuration.

Static Port (Binding)

Basically the solution for any connectivity issue from endpoints behind a VMM domain. I have seen it work with and without static binding of VLANs. In the past, I would associate this with the vSwitch policies, where as long as the hypervisor was seeing the leaf on the topology under virtual networking, no static binding was needed. Not the case anymore. The show vpc extended is the way to show the active vlans passing through from leaf to the host.

API Inspector

It is the easiest way to confirm specifics for API calls. With Postman, it is just a matter of copy and paste of the method, URL and payload while having the inspector running in the background for a specific configuration via GUI.

VMM AVE

Very similar process as deploying a distributed virtual switch, only that it needs a VLAN or VXLAN mode defined. If running VXLAN encapsulation, a multicast address is required along with a multicast pool, as well as a firewall mode. All the rest of the configuration is the same as far as adding vCenter credentials and specifying the Data Center name and IP address. After doing the process a few times without any success, and AVE not getting pushed to vCenter, I enabled infra-vlan on the AEP towards the host, which is a requirement when running VXLAN, and there it goes.

Follow-up

The offical ACI troubleshooting e-book has screenshots based on earlier versions but is still relevant as the policy model did not change. For most updated troubleshooting tools or tips, the BRKACI-2102 ACI Troubleshooting session from Cisco Live is recommended.

 

Cumulus VX Spine and Leaf

After hearing the word Cumulus twice from different initiatives on the same day, I decided I wanted to know more about Cumulus Networks in general, and playing with VX seems to be a great start. I am already running Vagrant and VirtualBox for other means, so having an additional box is easy. Well, the idea was just an additional box but after doing some GitHub investigative work, found out that there is already a pre-defined Cumulus Linux Demo Framework or Reference Topology available for consumption. I quickly followed this repository and built my own spine and leaf architecture:

cumulus

The whole process did not take more than 10 minutes. There is a lot that goes in the background, but still, not bad for a virtual non-prod environment or validation platform that supposedly has the same foundation as the Cumulus Linux and Cumulus RMP versions, including all the control plane elements.

The configuration is done on each of the VMs using the Network Command Line Utility (NCLU) or by editing the /etc/network/interfaces and /etc/frr/frr.conf files. This definitely requires some “essential” Linux skills. Multiple demos are available here to run using this topology, including NetQ. I have tested the config-routing demo and it worked perfectly with two spines, two leafs, and two servers. It uses an ansible playbook to push the configuration to the spine and leafs, as well as adding new interfaces to the servers for the connectivity test. A nice way to test the OSPF and BGP unnumbered concept. 

The fundamental piece is the FRR (Free Range Routing) responsible for EVPN, BGP, and OSPF functionality. Pete Lumbis did an excellent whiteboard session at Networking Field Day 17 by going over the building blocks followed by a demo on a similar topology running Cumulus VX.

Ansible Tower on Vagrant

I am still on the re-install apps land on the macOS, and this is a mini guide on how to install Ansible Tower using Vagrant for demo/trial usage only.

The first step is to install Vagrant if not already installed for other means. Vagrant relies on interactions with 3rd party systems, known as “providers”, to provide Vagrant with resources to run development environments.  I am running VirtualBox

To verify the installation of both Vagrant and VirtualBox:

vagrant --version

vboxmanage --version

Once the installation of both Vagrant and VirtualBox are completed, Ansible Tower can be initialized by creating a Vagrantfile with default instructions in the current directory as follows:

vagrant init ansible/tower

vagrant up

The process takes a few minutes the first time, and once complete:

vagrant ssh

The vagrant ssh command will give you your admin password and the Tower log-in URL (https://10.42.0.42). This is using the default (basic) settings in Vagrantfile and it can be edited further, including a more specific name for the ansible VM.

To verify the Ansible version:

ansible --version

At the moment, there are two trial/demo licenses available: one with enterprise features such as LDAP and Active Directory support, System Tracking, Audit Trails, Surveys, and one limited to 10 nodes and no expiration date, however, it does not include the enterprise features just listed. The open source alternative (or non-enterprise version) with no node limitation is the project AWX.

Below is the main (default) dashboard of Ansible Tower:

ansible tower

And here is a nice walk-through on the GUI: Ansible Tower demo.

Tip: if by any chance 10.42.0.42 can not be accessed the first time, check the routing table (ip r) and interfaces (ip a show) to see if 10.42.0.0/24 is listed on the Vagrant VM. If not listed, reinstall everything. 

Apstra in a Whiteboard

As an occasional and very ordinary writer, I think this topic deserves a “direct from the source” approach. I am definitely using credits from my blank slate bucket. In other words, nothing I write would be better than reading from who explained in a whiteboard at Networking Field Day 19 so simple and easy to understand what the Apstra AOS (Apstra Operating System) is all about and its building blocks.

Besides doing a great whiteboard session, @_vCarly also published an outline of that very busy morning at Apstra’s NFD19 Experience. It is a detailed narrative that goes from the reference architecture made of the AOS server sitting at the orchestration (or management) layer and agents installed on each individual switch (supporting modern leaf-spine designs or extensible to other environments) to the building blocks: logical device, rack type, template, blueprint, interface map, device profile, resources, and managed devices. They are all interconnected and it makes more sense when delving into the whiteboard. There is no better way to get a clear understanding of Apstra other than watching the original video followed by her narrative.

IMG_3761

On a side note, this is someone who I met in person for the first time, but who I have known for a while through videos as part of my initial Cisco ACI learning journey. I just wish my whiteboards were that decent and inspirational.

In addition to the whiteboard session, other highlights were around the ServiceNow integration delivered jointly with Network to Code, an overview and demo of Day 2 Operations via IBA (Intent-Based Analytics) with a write-up here as well, and a demo on AOS for additional context. The original videos are available at the Networking Field Day 19 portal.

NSX-T Logical Routers

Between a few VMworld 2018 sessions and a recent NSX-T Bootcamp, I believe I collected enough information to describe at a high level the new logical routing scheme within NSX-T. The interest is also being driven by an internal project.

The intent is to continue to “route as close as possible to the source” as all routing and switching is being done at the host level in software within the NSX overlay architecture, while the underlay infrastructure provides only transport and external connectivity.

Logical Routers Components

NSX-T has two logical routers components, namely the Services Router (SR) and the Distributed Router (DR). As the names imply, SR is where centralized services are provisioned such as NAT, DHCP, VPN, Perimeter Firewall, Load Balancing, etc., and DR performs distributed routing across all hosts participating in a given transport zone. This is very similar to the Distributed Logical Router (DLR) in NSX-v, except that there is no need for a DLR Control VM or dynamic routing protocols between DR and centralized services.

Apart from the logical router components being named SR and DR, the actual logical router naming convention configured within the NSX-T Manager is “Tier 0” and “Tier 1” router as described further when deploying single or two-tier routing/topologies.

Figure 1 is a conceptual diagram illustrating the SR and the DR placement within the NSX domain, for north-south (external networks) and east-west (internal networks) traffic respectively.

Screen Shot 2018-12-14 at 11.24.51 PMFigure 1 – Conceptual Design

Single Tier Topology

In a single tier topology, both SR and DR are known as Tier 0 Logical Router. In this architecture, upon creation of a Tier 0 Router with downlink interfaces to logical switches, Tier 0 Distributed Routers are automatically pushed to all Transport Nodes (compute hosts) participating in a transport zone. A Tier 0 DR instance is also automatically added to the Edge Node with the SR, which is instantiated the moment a service is enabled. By default, the link between the SR and the DR uses the 169.254.0.0/28 subnet and is auto-plumbed by NSX-T Manager. A default route is created on the DR with the next-hop pointing to the SR, and the connected routes of the DR are programmed on the SR with a next-hop pointing to the DR.

For east-west traffic, a packet coming from a virtual machine behind a DR to a virtual machine in another logical switch (same or different compute host) is routed at the local DR, same goes for the returning traffic, which is routed at the local DR first. For north-south traffic that traverses the Edge Node, the packet is also routed at the local DR first, and the returning traffic is routed at the local DR residing in the Edge Node before it is encapsulated and sent back to the source.

There is a lot that happens in the background, but from the perspective of the Tier 0 DR router, the logical switches are directly connected as south-bound switches, and the logical switches only see a single logical router or single routing construct upstream. Figure 2 depicts the physical and logical view with color-coded routers to indicate which one is SR, which one is DR within a single tier topology.

Screen Shot 2018-12-14 at 11.25.02 PM

Figure 2 – Single Tier Topology

Two-Tier Topology

In a two-tier (or multi) routing topology, the fundamentals of SR and DR remains the same, but the logical routers are named Tier 0 and Tier 1 routers and both are instantiated on the hypervisors of each transport node in a fully distributed architecture. The “RouterLink” between Tier 0 and Tier 1 routers is automatically configured with a /31 IP in the subnet range of 100.64.0.0 when the Tier 1 is connected to the Tier 0 router, same auto-plumbing process in the backend by NSX-T Manager. There is no routing protocol running between Tier 0 and Tier 1 routers. The NSX management plane knows about the connected routes on Tier 1 and creates static routes on the Tier 0 router with a next-hop in the subnet range of 100.64.0.0/10.

As with the single tier topology, the Edge Node also has instances of SR and DR locally, or Tier 0 and Tier 1. The major difference is that even though Tier 1 is being “distributed” across all Transport Nodes, it has tenant isolation from the other Tier 1 routers across the NSX domain. A Tier 1 can be removed from the environment without affecting any other tenant, completely independent (or isolated) given the multi-tenancy nature. Specific services can also be enabled on a Tier 1 router such as Load Balancing or NAT.

If there is a need for inter-tenant connectivity, traffic between tenants traverse the local Tier 1 as well as the Tier 0 routers in the transport node, and packets are routed locally by the Tier 1 before it hits the wire via Geneve encapsulation. Returning traffic is also routed at the local Tier 1 at the remote tenant. For north-south traffic that traverses the Edge Node, the packet is also routed at the local Tier 1 first, and the returning traffic is routed at the local Tier 0 and Tier 1 instantiated at the Edge Node.

Figure 3 depicts the physical and logical view with color-coded routers to indicate which one is Tier 0, which one is Tier 1 within a two-tier topology contained in each tenant.

Screen Shot 2018-12-14 at 11.25.10 PM

Figure 3 – Two-Tier Topology

Which One?

The decision of when and which topology to use will come down to business requirements. In a multi-tenancy environment, of any kind, two-tier routing has its place by providing tenant isolation and independent control over network and security policies. For some, it may simplify management, while for others, it may add complexity. The single tier topology is as “simple” as it could be. If there is no interest (or requirement) in separating routing domains for tenants/groups, then only Tier 0 can be deployed.

Recommended Sessions

These are the VMworld sessions which add more in-depth details with packet walk of the logical routing in NSX-T:

  • NET1127BU: NSX-T Data Center Routing Deep Dive
  • NET1561BU: Next Generation Reference Design with NSX-T Data Center (part 1)
  • NET1562BU: Next Generation Reference Design with NSX-T Data Center (part 2)

Credit

Thanks to my friend @LuisChanu who provided invaluable inputs and guidance.