Cited by 11IoT and Edge/Fog ComputingCloud Computing and Resource ManagementDistributed systems and fault tolerance

The DOI matches its Crossref record; 12 of the 12 references it cites were found in a registry or an index.

Edge Workloads Monitoring and Failover: a StarlingX-Based Testbed Implementation and Measurement Study

Open access
Abuibaid, Mohammed, Ghorab, Amir Hossein, Seguin-Mcpeake, Aidan, Yuen, Owen, Yungblut, Thomas, St-Hilaire, Marc·2022·IEEE Access

Abstract

With the ever-growing amount of time-critical, compute-intensive, and private IoT applications, the need for High Availability (HA) Edge Clouds becomes indispensable. Realizing HA Edge Clouds is inherently challenging due to the geographically-dispersed hierarchy of the Distributed Cloud Infrastructure (DCI). For example, frequent isolation between the central Cloud and Edge Clouds due to networking instability necessitates some autonomous operations at the Edge Clouds. Furthermore, because Edge Clouds have fewer resources than central Clouds, configuring the Edge functions (i.e., control, compute, and storage) in HA clusters will undoubtedly reduce downtime. However, it will limit the Edge scalability. To that end, StarlingX is developing an HA-protected and scalable DCI virtualization platform based on the open-source ecosystem, focusing on low-touch management of Edge Clouds. StarlingX provides a fault management service that realizes DCI-wide alarming and logging capabilities, allowing for rapid response to virtualized infrastructure events. Recently, the IETF Network Working Group proposed that monitoring both the DCI and the Edge workloads (software containers) is critical for an Edge Computing Platform to maintain HA IoT application deployment. Indeed, the possibility of the infrastructure remaining stable and healthy while the workloads suffer a fatal failure simultaneously necessitates failover functionality that monitors both the infrastructure and the Edge workloads. In this paper, we first propose a dynamic failover functionality that centrally monitors Edge workloads to recover from deployment or Edge node failures, motivated by the IETF direction. Second, we experimentally optimize the failover functionality for monitoring a microservice-architected IoT application deployed on a StarlingX-based DCI testbed to collect temperature sensor readings from Raspberry Pis. Regardless of how quickly the Edge workload health checks are collected, the recorded failover measurements reveal that the recovery time will not drop below a predetermined level controlled by Edge resources and network speed. Furthermore, reducing the statistics collection timeout reduces the recovery time of an Edge node failure. When the timeout value is less than the minimum achievable recovery time, false-positive failures (FPFs) can occur. Third, to supplement the StarlingX fault management service, we provide a modular implementation of the proposed failover functionality. Finally, we present the first-ever introduction of the StarlingX platform’s software stack to promote its use in academic research.

Overview

The claims and statistics of this paper haven’t been checked yet.

Run the check — free, no account needed. It reads the open-access text and checks the sources it cites.

A few free checks a day · papers already verified open instantly · results are public

Integrity signals

Registry

Crossref · 10.1109/access.2022.3204976

Cites

12 of 12 references verified0 citation errors · 0 not checkable

Statistics

Figures

FIGURE 1 The DCI control approaches and implementations taxonomy.
FIGURE 1 The DCI control approaches and implementations taxonomy.CC-BY · From the PDF
FIGURE 2 Comparison of Kubernetes, OpenStack and StarlingX DCI implementations.
FIGURE 2 Comparison of Kubernetes, OpenStack and StarlingX DCI implementations.CC-BY · From the PDF
FIGURE 3 Akraino's connected vehicle blueprint.
FIGURE 3 Akraino's connected vehicle blueprint.CC-BY · From the PDF
FIGURE 4 StarlingX edge virtualization platform.
FIGURE 4 StarlingX edge virtualization platform.CC-BY · From the PDF
FIGURE 5 StarlingX-based DCI testbed architecture.
FIGURE 5 StarlingX-based DCI testbed architecture.CC-BY · From the PDF
FIGURE 6 Temperature monitoring application architecture.
FIGURE 6 Temperature monitoring application architecture.CC-BY · From the PDF
FIGURE 7 Temperature graph as monitored from Temp-mon-web container.
FIGURE 7 Temperature graph as monitored from Temp-mon-web container.CC-BY · From the PDF
FIGURE 8 Breakdown of the recovery time objective.
FIGURE 8 Breakdown of the recovery time objective.CC-BY · From the PDF
FIGURE 9 Polling-based vs. event-driven monitoring services.
FIGURE 9 Polling-based vs. event-driven monitoring services.CC-BY · From the PDF
FIGURE 10 Proposed monitoring and failover process flowchart.
FIGURE 10 Proposed monitoring and failover process flowchart.CC-BY · From the PDF
FIGURE 11 Experiment 1: Effect of polling_period on the average recovery time.
FIGURE 11 Experiment 1: Effect of polling_period on the average recovery time.CC-BY · From the PDF
FIGURE 12 Experiment 1: Breakdown of the recovery time objective.
FIGURE 12 Experiment 1: Breakdown of the recovery time objective.CC-BY · From the PDF
TABLE 3. Experiment 1: Monitoring overhead vs. Polling period.
TABLE 3. Experiment 1: Monitoring overhead vs. Polling period.CC-BY · From the PDF
FIGURE 14 Experiment 2: Breakdown of the recovery time objective.
FIGURE 14 Experiment 2: Breakdown of the recovery time objective.CC-BY · From the PDF
Image 15
CC-BY · From the PDF
Image 16
CC-BY · From the PDF
Image 17
CC-BY · From the PDF
Image 18
CC-BY · From the PDF
Image 19
CC-BY · From the PDF

Verification

Claims the paper makes

The claims and statistics of this paper haven’t been checked yet.

Run the check — free, no account needed. It reads the open-access text and checks the sources it cites.

A few free checks a day · papers already verified open instantly · results are public

Claims other papers make about this one

Each is checked against this paper’s own text: does it say what the citing paper says it does?

Self-check

Percentages, sums and reported differences re-computed from the paper’s own numbers.

The self-check needs the paper’s full text.

Citations

Cites

Show all 12 references

Research works printed but not linked: 5

  1. 2021, StarlingX, R4.0
  2. 2021, Distributed Cloud Installation R4.0
  3. 2017, Mobile Edge Computing (MEC); Mobile Edge Management; Part 1: System, Host and Platform Management
  4. 2014, Network Functions Virtualisation (NFV); Architectural Framework
  5. Mohammed, 2021, StarlingX R4.0 Virtual All-in-One Duplex Distributed Cloud Infrastructure Installation Guidelines

Cited by

Sorted by citations

Metadata

Authors
Abuibaid, M., Ghorab, A. H., Seguin-Mcpeake, A., Yuen, O., Yungblut, T., & St-Hilaire, M.
Affiliations
  • Carleton University (CA)
  • Department of Systems and Computer Engineering, Carleton University, Ottawa, Canada
Corresponding author
Abuibaid, Mohammed
Venue
IEEE Access
Published
2022
Volume
10
Pages
97101-97116
ISSN
2169-3536 (ISSN-L)
OpenAlex
W4296437371
Cited by
11
References
12
Citations by year
2026: 4 · 2025: 4 · 2024: 2 · 2022: 1
FWCI
0.78
Type
journal article
Language
en
Open access
Locations
  • IEEE Access (publishedVersion, cc-by)
  • Carleton University's Institutional Repository (MacOdrum Library, Carleton University) (submittedVersion, cc-by-nc-nd)
  • DOAJ (DOAJ: Directory of Open Access Journals) (submittedVersion, cc-by-sa)
Topics
  • Physical Sciences › Computer Science › Computer Networks and Communications › IoT and Edge/Fog Computing
  • Physical Sciences › Computer Science › Information Systems › Cloud Computing and Resource Management
  • Physical Sciences › Computer Science › Computer Networks and Communications › Distributed systems and fault tolerance
Keywords
edge computing, high availability, distributed cloud infrastructure, workload monitoring, fault management, microservices, IoT applications, recovery time, testbed implementation

About these checks

Registry, retraction, Cites and statistics results are computed, not judged, with one exception: a printed reference that no index lists is read once by a model before it counts as a citation error. Claims are extracted by a model and kept only when their quote appears verbatim in the text; each cited source is then checked, with a model’s help, for whether it says what the claim relies on. Those verdicts can be wrong — read the claim’s quote and the cited source before relying on one.

Statistics and arithmetic are recomputed, not judged.

Confidence bands are shown only for fields calibrated on our annotated test set. None is calibrated yet, so no band is shown.

What counts as a claim ›How we measure confidence ›How we check this ›

Are you an author, or do you see a problem with this page? Request a review