Networking in EaaS (virtual networks)
Emulation-as-a-Service (EaaS) can simplify the provisioning of emulation for end-users' needs without requiring them to install and configure complex toolchains on their devices. Beside single machine instances the user is directly interacting with, more complex setups for networked services as in preserved business processes or research environments are required. This involves computer networking between nodes and machines which are accessiblenot directly, but over network links. Depending on the users' requirements the networking is just internal, and unlinked to the rest of the world or it can be required that access is possible from within the original, emulated environment to (parts of) the outside world or vice versa.
To illustrate the different requirements for EaaS networking a couple of use cases can help to understand the problem set. Starting from the early days of computing, many services especially in business environments are networked. Like for instance for databases there is a (single) server running the Database Management System (DBMS) and clients connecting to it over a network protocol. With the raising popularity of TCP/IP, networking spread to applications like email, file transfer protocols, network drives, or the world wide web. Modern WWW sites may provide additional features which use a database or other services in the back-end such as found for content management services or electronic shops. Other use cases include computer games either played in a LAN setup or over the internet. Early games depended on IPX/SPX networking, all newer ones switched to TCP/IP. Later on new services emerged like Voice over IP. The requirements of the various services regarding bandwidth and latency may differ significantly.
Different higher layer protocols depend on certain physical networks. Nevertheless, the underlying physical transport medium is usually only relevant as different computer platforms might provide different options like virtual Ethernet connections of various speeds or serial line interfaces (for modem connections). Operating system drivers might be needed for the hardware layer and for the higher layer protocols as they were not provided with all operating systems. While the case is comparably easy with Unix and Linux systems dating from 20 years ago, Microsoft and Apple OS added networking later on. The hardware drivers were usually provided by the manufacturers of the devices. Popular TCP/IP stacks for DOS and Windows 3.11 were NCSA Telnet and Trumpet Winsock. Later on Microsoft provided a fully functional TCP/IP stack for Windows 3.11 including fully operational DHCP client. Another challenge is the network configuration. Not all TCP/IP stacks implement BOOTP or DHCP for dynamic IP configuration. A future problem emerges with the switch from IPv4 to IPv6.
Networking in Emulators
Emulators implement hardware components in software which mimic the behavior of their physical counterparts. Modern, modular emulators like QEMU provide a couple of popular Ethernet cards like NE2000, NE2K, PCnet featuring 10Mbps, E100, E1000 (i82551, i82557b, i82559er) for faster connections up to Gigabit. Some aspects of network access require privileged operation executed by the emulator as it might need to modify the network routing table or bridging functionality of the host system. X86 virtualization software usually links quite directly to the host system via bridged, NATed or host-only networking, often providing the feature of more than one network interface provided to a guest. Some emulators offer just user mode networking, where the emulator acts as a normal network client within the host environment, which might limit the available protocols and functionality. In this case the emulator usually provides routing and NATing functionality on the IP layer. Often, the emulator or virtual machine provides higher layer network configuration like BOOTP/DHCP directly built-in into QEMU or VirtualBox. This prevents the use of non-IP higher layer protocols like IPX/SPX or AppleTalk.
Original environments with networking can be connected to each other either on the virtual hardware layer by bridging network interfaces to each other or routed networking on a higher layer protocol like TCP/IP. When directly bridged to each other on the same host system the virtual machines usually provide the software network stack. In cases of accessing the host networking via protocol routing (e.g. for NAT or host-only networking) special virtual network interfaces are required. Those are either provided by the virtual machine frameworks like from VMware, or they use available technology like TUN/TAP deployed by QEMU.
Networking in EaaS
The fundamental building block of an EaaS architecture are abstract emulation-components used to standardize deployment and to hide individual system complexity. An EC encapsulates various emulators, available either as open source or commercial products, into an abstract component with a unified set of software interfaces (API). Beside control interfaces for standard emulator features in combination with node- and user-management a networking control is needed. The task of configuring and providing networking in EaaS is somewhat more challenging. Different objectives need to be met, depending on the actual task. A general software network layer should be provided, which should be able to fulfill the following requirements:
- Bridge distributed running systems to each other (on a virtual Data Link Layer)
- Allow lower layer packet exchange (Data Link Layer, e.g. for Ethernet, TokenRing, … frames) to provide service for different higher layer protocols like NetBEUI, IPX, AppleTalk, IPv4, IPv6, …
- Connect to different system emulators in a standardized way
- Allow for network tunneling between EaaS instances and to end users
- Provide (controlled) break-out into today's networks (via NAT, proxy, …)
Idially, no privileged access to host resources is required to prevent security issues and simplify configuration.
The base for such a software network layer can be provided, e.g. with Virtual Distributed Ethernet (VDE). VDE, part of the virtualsquare research project, is an Ethernet compliant virtual network/softswitch that can span over a distributed set of physical machines connected through the Internet. The actual needed functionality depends on the use case.
Database Server and Clients
A typical use case depending on the availability of network connects are databases. Usually databases are deployed on a dedicated server and accessed over the network from (numerous) clients. For preservation and access through EaaS several scenarios are possible. Some setups may allow that server and clients are merged into one machine avoiding the need to create a network connection at all. This approach was used for the LINZ database preservation described in Euan's post. The server machine already provided all necessary components (web browser) to access the database. For large scale databases and complex setups, like different operating systems on the server and clients, at least two machines need to be preserved. Then, an appropriate network connection is to be provided and brought up, when a user wants to interact with the client. The bandwidth requirements depend on the actual database application but should usuallybe low. As the database server usually runs permanently, the client expects it to be running. Thus, it needs to be started or resumed before the client is started. In EaaS the user would get only a presentation of the client. Functions need to be implemented which automatically enable the server, when a user requests access to the preserved client. Depending on the user requirements as regards data re-use, the data might need to be extracted into today's user environments. Client implementations exist for many databases, which still run in today's working environments. For these scenarios only the database machine (running the DBMS) needs to be started and a direct network connection to the end user needs to be provided. Ideally, the connection is tunneled to the end user, which avoids open data connections between both sides. The client on the user side directly connects to the local end of the network connection, provided together with the EaaS access. Such a setup avoids creating a specific network tunnel between the EaaS provider and the user.
Networked computer games usually require at least two user instances running. Depending on the type of game one of the clients or a dedicated machine will provide server functionality. While early network games were content with dial-up network link speeds, newer games expect higher bandwidth and lower latencies provided by Ethernet links. Early games were using IPX/SPX over LAN connections, later on IPv4 took over. Different higher layer protocols (expecting broadcast functionality) need to be supported by the virtual network link. The latencies provided by today's WAN connections should be fast enough to suffice for early network games. Network games offer different numbers of simultaneous players. Beside minimal network and user configuration differences all clients are pretty much the same. Thus, ideally every client should be cloned and configured from a single instance to avoid keeping numerous client instances (full machine images and configuration) just for that purpose. The Eaas needs to provide the means to start and configure the server if required and to fire up the needed number of clients upon user request. Here, the users somehow should be able to join the same game.
Another use case involving networking between multiple machines are business processes or scientific research environments. Such configurations might have external dependencies like third party services accessed over the network. Either these services can be internalized to keep the original environment functional, or it could be tried to emulate the necessary features of the service. This could be very complex and thus impossible, if e.g. cryptographically secured connections are used. For simpler services it might be feasible to monitor and record the data exchange over the network for certain situations and play-back the answers of the service later on.
By Dirk von Suchodoletz, posted in Dirk von Suchodoletz's Blog
There are no comments on this post.