BRACELET

BRACELET: Robust Cloudlet Infrastructure for Scientific Instruments’ Lifetime Connectivity

Bracelet Brief Description: 

Bracelet is a set of network configurations and best practices that can be used in isolation or to act as a light-weight version of 4CeeD to be used in labs where an instrument’s Operating System is deprecated, no longer supported, deemed a security risk and cannot be included on the network. 

What problems Bracelet attempts to address: 

Without access to a network to save data, users are forced to fall back on legacy options like memory sticks, paper notebooks, or cobbling together their own unprotected network. This wastes time poses security risks (patches, malware), and forgoes the easy process of data collection and archival provided by modern LIM systems. Bracelet architecture uses white lists, DMZ zones, upstream communication only, and optionally a stripped-down version of 4CeeD with supported browsers to provide the benefits of a lab notebook system to Operating systems as old as Windows XP. Every several year’s new machines/instruments fall into a cycle where they are too costly to upgrade and must be taken off the network. Already, Windows 7 is quickly approaching its end of life. 

Bracelet Architecture:

State of current lab environments:

One of the major problems in technology today is the deprecation of older operating systems and the loss of continued vendor support. The most popular commercial operating system continues to be the various iterations of Microsoft Windows. The most recent release as of 2020 is Windows 10. Mainstream support for Windows 10 is scheduled to continue until Oct. 13, 2020, with extended support ending on Oct. 14, 2025. However, in academia and industry, many software services continue to run on legacy operating systems like Windows XP, and Windows 7. Microsoft ended mainstream support for Windows 7 on January 13, 2015, with extended support has ended on January 14, 2020. With the end of life (EOL) for Windows XP/7, Microsoft no longer releases critical bug fixes and security patches. Organizations running equipment on these operating systems can be exploited by hackers in a number of different ways. Different types of malware exist that can cripple a network with ransomware, loss of productivity, spread to other networks, and compromise intellectual property. Attacks like these typically target older operating systems. 

Machines and instrumentation in the material sciences are typically very expensive items, often ranging in the millions of dollars and expected usage is decades. The vendor software that drives some of these networked instruments is sometimes several iterations behind in operating systems.  Vendor software is often proprietary, not upgraded to run effectively on newer operating system versions, or if an upgrade is available it may cost nearly 6 figures in support/maintenance. 

At the University of Illinois, more than half of the major scientific instruments on campus and their software tools run Windows XP, Windows NT, Windows 2k, and even some isolated instances of Windows 3.11. These machines are offline and either cannot operate on higher bandwidth networks or are not patched as there is no longer support for them. 

Our goal with Bracelet was to deploy a new infrastructure on our campus across different research laboratories that run scientific instruments with the problems described above. Our initial research led us to focus on and develop a robust cloudlet-based infrastructure at the network edges. This cloudlet was a networked edge device and a surrogate to the real cloud, placed between the scientific instruments and cloud as the middle tier of a three-tier hierarchy: the scientific instrument, cloudlet, and cloud. The cloudlet would be placed within the campus building to shape and protect traffic from instruments in the campus building (e.g., MRL) to the campus node hosting the research cloud cluster. The cloudlet can play a foundational role in keeping the instrument connected throughout its lifetime (10–15 years), continuously providing the otherwise missing performance and security features for the instrument as its OS ages. Past research with BRACELET represented an integrated three-tier infrastructure that integrated and innovated the existing campus network, cloud, and security infrastructure with the 4CeeD data upload service and its robust cloudlet infrastructure.

Our current research found that network shaping, pre-analysis of data before being uploaded to the cloud, while useful, was a more complicated approach to our current use cases. We focused more on finding a way to incorporate our existing DIBBS project, 4CeeD, along with some switch maintenance that would allow users the functionality of the 4CeeD cloud-based notebook storage and improved security.

4CeeD Description: 4ceed.github.io

4CeeD is an open-source laboratory information management system that curates scientific data to a private cloud. With similarities to vendors like Dropbox, 4CeeD fills a specific niche where others leave off. File previews, Jupyter Notebook integration, flexible naming conventions, metadata template/schemas, text annotations, and real-time extraction/translation of metadata from supported file formats. 

What problems 4CeeD attempts to address: 

Most cloud storage solutions don’t allow users to annotate information to their files. Images taken from analysis instruments (SEM, TEM, AFM) may often have proprietary file formats that cannot be viewed as a preview without the time/cost of converting to a .tif and losing valuable instrument metadata. It can be very challenging for users to track the various phases of an experiment and attempt to recreate it without a system that offers what 4CeeD does. 

4CeeD has been a very popular system with students, classes, faculty, and the research staff that maintain the lab instruments. 

The machines that run Bracelet with 4CeeD have access to a streamlined 4CeeD interface that supports upstream only and a simpler interface to account for older web browsers that run on machines like Windows XP that cannot render modern javascript libraries. 

The 4CeeD tool can only function when the instrument’s operating system (OS) is Windows 7 or higher, allowing instruments to have the computational capability and network speed to be part of a distributed cloud platform and to have all the necessary security patches to be connected to the campus network. 

4CeeD with Bracelet Front End

Users using Bracelet with 4CeeD have limited access to 4CeeD features due to the nature of javascript support, and downstream security. Users can access data uploaded via the bracelet instance

Bracelet w/4CeeD requirements

In order to use a Bracelet environment, a few requirements are necessary:

  • First and foremost is a running 4CeeD instance that uses a MongoDB instance that is accessible to the Bracelet server. This is because the Bracelet instance will store any files uploaded from the Bracelet server to the same database that 4CeeD uses. In this manner, files uploaded through 4CeeD are instantly available from the 4CeeD interface.
  • The Bracelet server runs very similarly to the 4CeeD server, in that it runs as a collection of microservices encapsulated in Docker containers. The containers are configured to run under the latest version of Docker Community Edition (Docker CE). The containers that run on the Bracelet servers are bracelet web frontend, along with a RabbitMQ instance and the image preview extractor. This means that image thumbnails will only initially show up on the bracelet server, since they are stored on the frontends. To show the thumbnails in the 4ceed instance, an image preview extraction will need to be run on the uploaded data.
  • Custom.conf files need to be configured to have the frontend point to the existing 4CeeD MongoDB database.
  • A reverse proxy like NGINX or Apache that allows the redirecting of URLs and obfuscation of port numbers. For example, bracelet.4ceed.illinois.edu:9000 can be accessed from just bracelet.4ceed.illinois.edu.
  • A valid SSL certificate for the curator and NGINX to use.
  • The following network configuration for an HP switching environment. 
    • Our HP/Aruba switches have a feature that allows us to isolate ports and/or L2 VLANs from each other.  On the bracelet network for each switch, we will turn on this port isolation. This means that ports on the network cannot directly communicate with each other.  We also turn this on for each interface on the bracelet network which tells the interface it can only communicate on that VLAN. If someone were to move one of the ports on a bracelet network to another VLAN, it won’t work.
    • The last thing we have is an outbound ACL on the router which blocks all traffic except for that coming from the bracelet server networks and some essential services such as:
      • NTP
      • Active Directory
      • DNS

The Bracelet software can be downloaded here: 

https://gitlab.com/uiuc-4ceed/bracelet

The 4CeeD software can be download here:

https://gitlab.com/uiuc-4ceed/4CeeD

Bracelet – Stand Alone Hp Switch settings:

    • Our HP/Aruba switches have a feature that allows us to isolate ports and/or L2 VLANs from each other.  On the bracelet network for each switch, we will turn on this port isolation. This means that ports on the network cannot directly communicate with each other.  We also turn this on for each interface on the bracelet network which tells the interface it can only communicate on that VLAN. If someone were to move one of the ports on a bracelet network to another VLAN, it won’t work.
    • The last thing we have is an outbound ACL on the router which blocks all traffic except for that coming from the bracelet server networks and some essential services such as:
      • NTP
      • Active Directory
      • DNS

Acknowledgment: This research was funded by the National Science Foundation (award number 1659293). The opinions, findings and conclusions or recommendations expressed in this paper are those of the authors and do not necessarily reflect the view of the National Science Foundation.