U.S. patent application number 17/726087 was filed with the patent office on 2022-08-11 for mounting a shared data store of a server cluster on a client cluster for use as a remote data store.
The applicant listed for this patent is VMware, Inc.. Invention is credited to Peng DAI, Mansi SHAH.
Application Number | 20220253229 17/726087 |
Document ID | / |
Family ID | |
Filed Date | 2022-08-11 |
United States Patent
Application |
20220253229 |
Kind Code |
A1 |
DAI; Peng ; et al. |
August 11, 2022 |
MOUNTING A SHARED DATA STORE OF A SERVER CLUSTER ON A CLIENT
CLUSTER FOR USE AS A REMOTE DATA STORE
Abstract
The disclosure herein describes mounting a shared data store,
remote from a client cluster, as a remote data store on the client
cluster. An abstraction interface of the remote data store on the
client cluster is configured to receive data operations that are in
a local data store-based format. A control path interface is
established between the server cluster and the client cluster, and
network location data associated with the shared data store is
received by the client cluster via the established control path
interface. Based on the network location data, a data path
interface is established between the client cluster and the shared
data store of the server cluster, whereby data operations directed
to the abstraction interface of the remote data store on the client
cluster are routed to the shared data store of the server cluster
via the established data path interface.
Inventors: |
DAI; Peng; (Boston, MA)
; SHAH; Mansi; (Palo Alto, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
VMware, Inc. |
Palo Alto |
CA |
US |
|
|
Appl. No.: |
17/726087 |
Filed: |
April 21, 2022 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
16718109 |
Dec 17, 2019 |
11340807 |
|
|
17726087 |
|
|
|
|
International
Class: |
G06F 3/06 20060101
G06F003/06 |
Claims
1. A method for remotely mounting a shared data store as a remote
data store on a client cluster, the method comprising: receiving,
by a processor of the client cluster, a request to mount the shared
data store of a server cluster as a remote data store of the client
cluster, wherein the server cluster is remotely located across a
network from the client cluster; configuring, by the processor, an
abstraction interface of the remote data store to be exposed to
entities of the client cluster, wherein the abstraction interface
is configured to receive data operations that are in a local data
store-based format; establishing, by the processor, a control path
interface between the server cluster and the client cluster;
receiving, by the processor, network location data associated with
the shared data store of the server cluster via the established
control path interface; and based on the network location data,
establishing, by the processor, a data path interface between the
shared data store of the server cluster and the remote data store
on the client cluster, whereby the shared data store of the server
cluster is mounted as the remote data store of the client cluster
such that data operations directed to the abstraction interface of
the remote data store of the client cluster are routed to the
shared data store of the server cluster via the established data
path interface.
Description
CROSS-REFERENCE TO RELATED APPLICATION(S)
[0001] This application is a continuation of U.S. patent
application Ser. No. 16/718,109 filed Dec. 17, 2019, entitled
"Mounting a Shared Data Store of a Server Cluster on a Client
Cluster for Use as a Remote Data Store" the entirety of which is
incorporated herein by reference.
BACKGROUND
[0002] Hyperconverged infrastructure (HCI) systems with fixed
computation to storage ratios and homogeneous storage classes are
widely adopted in both on-premise and cloud environments for the
simplicity, scalability, and economics they offer, as determined by
the hardware constraints, software limitations, and business
considerations. However, the fixed computation resource to storage
resource ratio results in a lack of independent scaling of those
resources and leads to "stranded capacity", where one or more types
of resources in a cluster can be left idle. Such efficiency issues
are exacerbated when clusters are deployed at scale.
BRIEF DESCRIPTION OF THE DRAWINGS
[0003] The present description will be better understood from the
following detailed description read in light of the accompanying
drawings, wherein:
[0004] FIG. 1 is a block diagram illustrating a system configured
for enabling client clusters to mount shared data stores of server
clusters as remote data stores according to an embodiment;
[0005] FIG. 2 is a block diagram illustrating a system configured
for mounting a remote data store in a client cluster based on
established control and data paths from a shared data store of a
server cluster according to an embodiment;
[0006] FIG. 3 is a block diagram illustrating a system for routing
of a data operation from a VCI of a client cluster to a local data
store and/or a shared data store of a remote server cluster
according to an embodiment;
[0007] FIG. 4 is a diagram illustrating a data store sharing
dashboard graphical user interface (GUI) configured to display data
store sharing information according to an embodiment;
[0008] FIG. 5 is a block diagram illustrating states of operation
of a remote directory client of a remote data store according to an
embodiment;
[0009] FIG. 6 is a flow chart illustrating a computerized method
for remotely mounting a shared data store as a remote data store on
a client cluster according to an embodiment;
[0010] FIG. 7 is a flow chart illustrating a computerized method
for maintaining a remote directory instance on a client cluster and
routing data operation instructions to a shared data store based on
the remote directory instance according to an embodiment; and
[0011] FIG. 8 illustrates a computing apparatus according to an
embodiment as a functional block diagram.
[0012] Corresponding reference characters indicate corresponding
parts throughout the drawings. In FIGS. 1 to 8, the systems are
illustrated as schematic drawings. The drawings may not be to
scale.
DETAILED DESCRIPTION
[0013] Aspects of the disclosure provide a computerized method and
system for remotely mounting a shared data store as a remote data
store on a client cluster. A processor of the client cluster
receives a request to mount the shared data store of a server
cluster as a remote data store of the client cluster. In response,
an abstraction interface of the remote data store is configured to
be exposed to entities of the client cluster and to receive data
operations that are in a local data store-based format. A control
path interface is established between the server cluster and the
client cluster and network location data associated with the shared
data store is received by the client cluster. Based on the network
location data, a data path interface is established between the
shared data store of the server cluster and the remote data store
of the client cluster, whereby the shared data store of the server
cluster is mounted as the remote data store of the client cluster
such that data operations directed to the abstraction interface of
the remote data store of the client cluster are routed to the
shared data store of the server cluster via the established data
path interface.
[0014] The disclosure addresses the challenges of preventing
"stranded capacity" in hyperconverged infrastructure (HCI) systems
and enabling the sharing of data store capacity across clusters
within such systems. By providing for remote use of shared data
stores on server clusters, independent scaling of computation and
storage resources across clusters is enabled and more efficient use
of storage resources via storage tiers is allowed. The disclosure
operates in an unconventional way at least by enabling the
discovery and mounting of shared data stores as remote data stores
on client clusters while maintaining the same experience for
entities within the client clusters, including use of interfaces
and features for accessing the remote data stores, such as data
path, control path, storage policy-based management, and other
related HCI management. Customers' use of the described features in
an HCI system improves efficiency of storage resource use and
thereby reduces the customers' costs associated with the system.
For instance, rather than deploying additional clusters when only
additional storage resources are needed, available shared data
stores are leveraged, saving the customer the cost of deploying the
additional clusters. Further, the human-machine interface and user
experience are enhanced as additional storage may be made available
without interruption to the user.
[0015] FIG. 1 is a block diagram illustrating a system 100
configured for enabling client clusters 102-104 to mount shared
data stores 140 and 148 of server clusters 106-108 as remote data
stores of client clusters 102-104 according to an embodiment. In
some examples, the client clusters 102-104 and the server clusters
106-108 are components in an HCI system that is configured to host
virtual computing instances (VCIs) such as virtual machines (VMs),
container-based VCIs, or the like (e.g., VCIs 110-112, 122-124,
134-136, and 142-144). It should be understood that VCIs
instantiated, managed, and/or otherwise hosted in the system 100
may be any type of VCI without departing from the description
herein. Alternatively, or additionally, the system 100 are
generally operable in non-virtualized implementations and/or
environments without departing from the description herein.
[0016] In addition to the VCIs hosted on the clusters, the clusters
102, 104, 106, and 108 each include virtual storage networks 114,
126, 138, and 146 respectively. Each virtual storage network is a
component of a cluster that virtualizes storage of data that is
used by the VCIs hosted on the cluster and/or other components of
the cluster. In some examples, the virtual storage networks 114,
126, 138, and 146 are configured as VMWARE Virtual Storage Area
Networks (vSANs). Within the virtual storage networks, data stores
(DSs) are stored and managed (e.g., local DSs 116 and 128, remote
DSs 118, 120, 130, and 132, and shared data stores 140 and 148).
The data stores in the virtual storage networks may be stored in
the form of data objects, container-based data stores, file
system-based data stores, databases, or other types of data stores
without departing from the description herein. In examples where
the virtual storage networks are configured as vSANs, the data
stores are configured based on Storage Policy-Based Management
(SPBM).
[0017] Each of the client clusters 102 and 104 are configured to
include a local data store (e.g., local data stores 116 and 128
respectively) that is configured to store the data within the
respective client cluster. For instance, the data stored in the
local data store 116 of the client cluster 102 may include data
associated with one of the VCIs 110-112 hosted on the client
cluster 102 and/or data associated with other components of the
client cluster 102, such as metadata used during management and/or
hosting of the VCIs 110-112. In further examples, each of the
server clusters 106-108 are also configured to include local data
stores that are not used as shared data stores and are not
pictured.
[0018] In addition to the local data stores 116 and 128, the client
clusters 102 and 104 are configured to each have two mounted remote
data stores. The client cluster 102 is configured with a remote
data store 118 mounted for accessing the shared data store 140 of
the server cluster 106 and a remote data store 120 mounted for
accessing the share data store 148 of server cluster 108. The
client cluster 104 is configured with a remote data store 130
mounted for accessing the shared data store 140 of the server
cluster 106 and a remote data store 132 mounted for accessing the
share data store 148 of server cluster 108. The remote data stores
described herein, when mounted in a client cluster, are linked to a
shared data store on another cluster (e.g., server clusters 106
and/or 108), such that data stored by the client cluster and/or
components thereof on the remote data store is transferred or
routed from the client cluster to the associated shared data store
of the linked server cluster. In this way, the client cluster is
configured to enable hosted VCIs and other components to make use
of available storage capacity of the server cluster. In some
examples, the link(s) or interface(s) established between the
remote data stores and shared data stores are configured such that
hosted VCIs on the client cluster are enabled to interact with the
remote data stores using the same operations and/or methods that
they use to interact with the local data store(s) of that client
cluster. The mounting of the remote data stores and associated
formation of links or interfaces to shared data stores on server
clusters is described in greater detail herein.
[0019] It should be understood that, while the client clusters are
illustrated as having mounted remote data stores to shared data
stores on the server clusters, in other examples, a server cluster
may include a remote data store mounted to make use of a shared
data store on another server cluster or on a client cluster.
Further, a client cluster may include a remote data store mounted
to make use of a share data store on another client cluster. As
such, a "client cluster" may behave as a "server cluster" to
another cluster when it shares a data store and that other cluster
mounts a remote data store to the share data store and a "server
cluster" may behave as a "client cluster" to another cluster when
it mounts a remote data store to a data store being shared by the
other cluster. Further, it should be noted that shared data stores
(e.g., shared data stores 140 and 148) of server clusters may be
mounted as, or otherwise linked to, multiple remote data stores
(e.g., shared data store 140 is mounted as remote data store 118 in
client cluster 102 and as remote data store 130 in client cluster
104). This enables multiple client clusters to store data in a
single shared data store.
[0020] In other examples, system 100 includes one or more server
clusters that do not host any components for performing
computations, operations, or the like (e.g., VCIs) and include only
shared data stores that can be mounted as remote data stores by
client clusters in the system. Additionally, or alternatively, the
system 100 includes one or more client clusters that include no
local data store and are configured to use mounted remote data
stores for all data storage associated with the cluster components
therein, such as hosted VCIs. It should be understood that more,
fewer, or different combinations of cluster configurations may be
used in a system without departing from the description herein.
[0021] FIG. 2 is a block diagram illustrating a system 200
configured for mounting a remote data store 118 in a client cluster
102 based on established control and data paths 260 and 262 from a
shared data store 140 of a server cluster 106 according to an
embodiment. In some examples, the client cluster 102 and server
cluster 106 are configured as described with respect to FIG. 1
(e.g., server cluster 106 may be configured to host VCIs 134-136 as
illustrated in FIG. 1, but they are not illustrated here for the
sake of clarity).
[0022] In addition to the local data store 116 and the remote data
store 118, the virtual storage network 114 of the client cluster
102 includes a local directory service 250 and an object manager
client 254. In some examples, the local directory service 250 and
the local directory service 256 of the virtual storage network 138
of the server cluster 106 are configured to include Cluster
Monitoring, Membership, and Directory Services (CMMDS) configured
to operate with data stores in vSAN-based networks 114 and 138
respectively. The local directory service 25 stores metadata and/or
other information associated with the structure and/or location of
data stored in the local data store 116. For instance, the local
directory service 250 may include up-to-date address information
(e.g., Internet Protocol (IP) addresses or other types of
addresses) of data objects and/or other data structures within the
local data store 116. Similarly, the local directory server 256 may
include up-to-date address information of data objects and/or other
data structures within the shared data store 140 and/or location or
address information associated with accessing the object manager
258.
[0023] The remote data store 118 of the client cluster 102 is
configured to include a remote directory instance 252 and make use
of the object manager client 254 when establishing and making use a
control path 260 and a data path 262 between the remote data store
118 and the shared data store 140 as described herein. During the
process of mounting the shared data store 140 as the remote data
store 118 on the client cluster 102, the control path 260 is
established, via one or more interfaces, between the virtual
storage network 138 of the server cluster 106 and the virtual
storage network 114 of the client cluster 102. Establishing the
control path 260 further includes the creation of the remote
directory instance 252 and the linking of the remote directory
instance 252 to the local directory service 256, such that at least
a portion of the information stored in the local directory service
256, such as the address information of data structures in the
shared data store 140, access information associated with the
object manager 258, and/or other associated metadata (e.g.,
key-value mappings, data identifying physical nodes in the cluster,
network interfaces, configuration information for objects in the
cluster, location information for storage components, rates and/or
sizes associated with components, where objects are served at any
point in time through a particular object manager, etc.).
[0024] In some examples, a directory service resolver component of
the remote directory instance 252 is configured to resolve logical
identifiers or addresses to specific nodes for data operation
routing via the data path 262 as described herein. The directory
service resolver is further configured to monitor mappings of
logical addresses to specific nodes and interfaces thereof on an
ongoing basis via subscription to the directory instance 252 of the
client cluster 102. The object manager client 254 may be configured
to interact with the directory service resolver to obtain routing
information. The directory service resolver may further maintain a
cache of the mappings. In further examples, a separate directory
service resolver cache is maintained for each cluster.
[0025] In other words, a component in the client cluster, such as
the directory service resolver component or the object manager
client 254, can selectively subscribe to one or more entries in the
client directory service so that they get notified if changes are
made to those entries. On the other hand, all changes to the server
directory service pertaining to the client are pushed to the client
cluster unconditionally, which may be referred to as
replication.
[0026] In some examples, the information transferred from the local
directory service 256 to the remote directory instance 252 is used
by the virtual storage network 114 to establish the data path 262,
including generating and/or configuring the object manager client
254 to interact with the object manager 258 of the shared data
store 140 via the established data path 262. For instance, address
information or other access information may be included in the
remote directory instance 252 that indicates a location of the
object manager 258 and/or an interface with which the object
manager 258 can be interacted and/or contacted. The object manager
client 254 is configured to interact with the object manager 258 to
send and receive data operations and/or other data path-based
messages in order to enable the use of the shared data store 140 by
entities on the client cluster 102. In examples where the local
directory service 256 and the associated remote directory instance
252 are configured as CMMDS-based services, such configuration
enables the remote directory instance 252 to be a partial or
complete replication or copy of the local directory service 256 of
the server cluster 106 to support data path operations, file system
operations (e.g., Object Store File System (OSFS) operations),
and/or other management operations of the shared data store 140 of
the server cluster 106.
[0027] FIG. 3 is a block diagram illustrating a system 300 for
routing of a data operation 364 from a VCI 110 of a client cluster
to a local data store 116 and/or a shared data store 140 of a
remote server cluster according to an embodiment. In some examples,
the system 300 is a subsystem of the systems 100 and/or 200 of
FIGS. 1 and 2 respectively. The VCI 110 is configured to send file
system-based data operation 364 to be performed on one of the local
data store 116 or remote data store 118. The data operation 364 may
include a write operation configured to write data to the targeted
data store, a read operation configured to read data from the
targeted data store, an operation for creating a directory, and/or
creating a file, etc. The VCI 110, as illustrated, is hosted in the
user level of the client cluster and is configured to send and
receive file system-based data operations and/or messages, wherein
stored data is referred to according to a hierarchical file system
(e.g., folders that contain other folders and/or files of data) or
the like. Further, it should be understood that, while the VCI 110
is illustrated at the user level, in some examples, the VCI 110
includes both user-level and kernel-level components, such that,
depending on the type of operation, the operation 364 may originate
from either the user-level components or the kernel-level
components (e.g., object lifecycle operations such as creation and
deletion may originate from the user level while data operations
such as read and write operations may originate from both levels).
Whether the data operation 364 is targeted at the local data store
116 or the remote data store 118, the format of the data operation
364 is substantially the same, such that the VCI 110 may be
agnostic of whether the data operation 364 is targeted at a local
data store 116 or a remote data store 118 and, thereby, a shared
data store 140 on a remote server cluster as described herein.
[0028] The data operation 364 is provided to a file system
abstraction interface 366 of the client cluster that is configured
to receive file system-based data operations and transform them
into object-based data operations (e.g., data operations configured
for compatibility with object-based data storage for which the data
stores 116, 118, and 140 are configured) to be routed to object
manager client modules (e.g., object manager client 254) at the
kernel level of the client cluster as illustrated. The object-based
data operation 368 is routed to the object manager client 254 when
the data operation 368 is targeted at the local data store 116 or
when the data operation 368 is targeted at the remote data store
118. In some examples, the file system abstraction interface 366 is
configured to receive data operations from entities in the user
level that are in a local data store-based format (e.g., a format
that includes a target data store indicator that points to a
specific data store within the client cluster, whether that be a
local data store of the client cluster or a remote data store of
the client cluster that is linked to a shared data store elsewhere)
and to route the data operations to either a local data store or a
remote data store based on the information in the data operation.
As a result, entities on the user level that provide the data
operations may be agnostic regarding whether the data operations
are being routed to a local data store or a remote data store.
[0029] In some examples, the abstraction interface 366 takes the
form of one or more file system containers (e.g., OSFS containers)
for hosts in the client cluster on behalf of the shared data store
in the server cluster. The file system containers are responsible
for maintaining the runtime mapping (e.g., using the remote
directory instance 252) between the remote data store 118
instantiated on the client cluster and the shared data store 140 on
the server cluster. This mapping enables all control path and data
path operations targeting the remote data store 118 to be
redirected to the shared data store 140. Ultimately, a manager or
controller module holds the source of truth for the mapping and
pushes the mapping down through a host synchronization process to
ensure each host in the client cluster has a consistent view of the
real-time mapping. On the host side, the file system kernel module
receives the mapping from a manager module (e.g., vSAN VMKCTL) and
keeps the state in the kernel. Hosts cache the mapping received
from the file system kernel module. The file system user space
daemon sits at the junction of various components and is stateless
with respect to the mapping. The file system user space daemon gets
the mapping from file system kernel module on a per operation basis
involving "lookup" and/or "read directory" operations and from
hosts for namespace operations such as create, delete, and
rename.
[0030] In some examples, the mapping includes the container ID and
an alias indicator (e.g., "aliasOf" tuple). The alias indicator is
a property introduced for use with logical data stores which
provides a namespace that is separate from that of the default
local data store for the purpose of role-based access control.
Since logical data stores share the same physical cluster with the
default local data store, they do not contribute additional
capacity beyond which is provided by the default local data store.
The alias indicator field takes the form of a file system container
ID that identifies the default local data store, which is also the
cluster UUID of the cluster. In the case of remote data stores, the
alias indicator field is used to identify the server cluster from
which the shared data store is being mounted. From a capacity
accounting perspective, a remote data store is as much an alias of
the shared data store it is mounting as the logical data store is
to the default local data store. In addition to the server cluster,
the mapping also identifies the shared data store being mounted
(e.g., whether it is a logical or default data store). To do that,
the remote data store uses the same container ID as the shared data
store it is mounting.
[0031] In examples where the object-based data operation 368 is
routed to the local data store 116 along the illustrated local data
path, the data operation 368 may be transferred between the object
manager client 254, the associated local object manager 370, and
the local data store 116 where the data operation 368 is performed
(e.g., data is written and/or read according to instructions of the
data operation 368). The local directory service 250 is configured
to store network location information and other metadata associated
with the local data store 116 and the local object managers and
clients associated therewith and it may be accessed by the
components of the data path for use in accurately routing the
object-based data operation 368.
[0032] Alternatively, in examples where the data operation 368 is
routed to the remote data store 118, the operation 368 is routed to
the object manager client 254 and then along data path 262 to the
object manager 258 of the shared data store 140 of the remote
server cluster, as described herein. The remote directory instance
252 includes network location information and other metadata
associated with the shared data store 140 and object manager 258
obtained from the local directory service 256 on the server cluster
and may be accessed by the object manager client 254 for use in
accurately routing the object-based data operation 368 to the
shared data store 140. Upon arrival, the data operation 368 may be
performed on the shared data store 140 and any response of the data
operation 368 may be returned along the illustrated data path 262
to the client cluster and then back to the VCI 110.
[0033] In some examples, the object manager and associated client
components are configured to include Distributed Object Manager
(DOM) modules (e.g., based on VMWARE DOM architecture). DOM modules
used within the data path of a remote data store as described
herein may include DOM clients (e.g., object manager client 254),
DOM owners (e.g., object manager 258), and/or DOM components, which
may be included in or separate from the object manager 258 as
illustrated. In such examples, establishing the data path 262 and
creating an associated data object includes picking a healthy and
reachable host from the server cluster and instantiating the DOM
owner on that host. Once the data object to be managed by the DOM
owner is fully created, the DOM owner may abdicate to one of the
hosts of the server cluster that contains data components of the
created data object. A Cluster Level Object Manager (CLOM) of the
server cluster may attempt to balance data component placement
across the cluster. Further, accessing data objects that already
exist on shared data stores may include DOM clients on client
clusters determining server clusters of data objects from an
input/output control (IOCTL) module initially. DOM clients may also
store the associated server clusters and any other metadata for
future use (e.g., in a remote directory instance 252).
[0034] The DOM components may be arranged such that the DOM client
is located on the client cluster and the DOM owner and associated
DOM components are located on the server cluster. It should be
understood that, in other examples, different arrangements may be
used without departing from the description herein. For instance,
the DOM client and DOM owner may be located on the client cluster
while only the DOM components are located on the server cluster.
Such an arrangement requires no network hops between the DOM client
and DOM owner, but the client cluster must have full read-write
access to the directory service of the server cluster, the owner
must consult with a local Cluster Level Object Manager Daemon
(CLOMD) for data placement decisions, the client must join the
server cluster for DOM owner election and failover, and the
arrangement prevents shared access of the same data object within
or across clusters. In this "smart client" arrangement, the client
is kept out of the server cluster and the server is largely
agnostic of the client and shared access of the same object within
or across clusters is enabled.
[0035] FIG. 4 is a diagram illustrating a data store sharing
dashboard graphical user interface (GUI) 400 configured to display
data store sharing information according to an embodiment. In some
examples, the data store sharing dashboard GUI 400 is associated
with a cluster (e.g., client cluster 102, server cluster 106) and
is configured to display information about the current state of
storage capacity usage in the cluster. The GUI 400 includes a pie
chart 402 that provides a visualization of the fractional amounts
of the capacity of the cluster that are occupied by local data
storage, remote data storage, and/or capacity of the cluster that
is currently free space. An associated GUI component 404 provides
specific data values reflecting the information that is provided by
the pie chart 402. For instance, as illustrated, the cluster that
is described by the GUI 400 has a local data store capacity of 10
terabytes (TB). 4 TB of that storage capacity is free space. The
cluster further has a remote data store capacity of 5 TB. The total
free space of the cluster is 5 TB. The local capacity used by
remote clusters is 5 TB and the number of clusters mounted to the
local data store is seven. The remote capacity used by this cluster
on mounted data stores is 1 TB. In other examples, more, less, or
different information may be displayed about the overall usage of
the associated cluster without departing from the description
herein.
[0036] The GUI 400 further includes a table 406 that displays
information about the local and remote data stores that are mounted
on the cluster. The illustrated table 406 includes example
information about three data stores, DS_0, DS_1, and DS_2. DS_0 and
DS_1 are local data stores and DS_2 is a remote data store. The
information displayed about each of the data stores include total
capacity, current free space, and clusters to which each data store
is mounted. In other examples, more, less, or different information
may be displayed about the data stores without departing from the
description herein.
[0037] In some examples, the GUI 400 is further configured to
enable users to select specific clusters to view (e.g., cause the
GUI 400 display overall capacity usage information and mounted data
store information about a specific cluster), change configurations
and/or settings of clusters or data stores (e.g., change whether a
data store is able to be mounted remotely, change how much capacity
of a data store is able to be used remotely, etc.), and/or mount,
unmount, or otherwise change how data stores are mounted on
clusters. This may include enabling a user to select a data store
of a cluster, identify client clusters to which the selected data
store may be mounted, validate the potential client clusters, and,
if validated, mount the selected data store on one or more of the
client clusters as described herein. The GUI 400 may further enable
users to control and/or manage the sharing of data store capacity
between clusters in other ways without departing from the
description herein.
[0038] FIG. 5 is a block diagram 500 illustrating states of
operation of a remote directory client of a remote data store
according to an embodiment. It should be understood that the remote
directory client configured to operate based on these described
states may be associated with a remote directory instance of a
remote data store such as remote directory instance 252 of remote
data store 118 described herein. In some examples, the remote
directory client is responsible for joining a directory service
that is configured by the management plane. The discovery
functionality of the remote directory client refers to the runtime
state of the server cluster, e.g., partitions, cluster membership,
and role of the hosts.
[0039] In the discovery state 502, the remote directory client is
configured to activate a discovery protocol using a list of
addresses (e.g., unicast addresses) for each host in the server
cluster. The client attempts to discover server cluster
configuration, including cluster membership, available partitions
and/or capacity, and identifying a master host for each partition,
by sending out discovery messages to each known host in the server
cluster (e.g., by User Datagram Protocol (UDP)). After the client
selects an optimal server cluster partition and discovers its
master host, it initiates a handshake with the master host and
registers itself with, or subscribes to, the master host as an
interested client. Selecting an optimal server cluster may include
selecting and joining the largest master host or otherwise the most
optimal host found at the point a defined discovery timeout period
ends (e.g., ten seconds), as illustrated at 508. Alternatively, at
510, if the client becomes isolated from the server cluster and
unable to join any server host or partition a defined timeout
period (e.g., the DISCOVERY_APD timeout period), the client is
configured to effectively disable the active directory by
discarding all content and then it may resume the discover state
502.
[0040] At the rejoin state 504, the client receives an initial
snapshot of the directory service information of the server cluster
with which it is joined. In some examples, the client merges the
new directory snapshot with its active directory information (e.g.,
the information currently in the remote directory instance). If the
rejoin process fails, the client returns to the discover state 502
at 512. Alternatively, if the rejoin process finishes successfully
at 514, the client checks if the joined partition is a majority
partition (e.g., a server cluster partition that includes, as
member nodes, a majority of all nodes configured in the server
cluster) at 516. If the partition to which the client is joined is
not a majority partition, the client transitions to the client
state 508 and background discover handshakes are activated at 518.
Alternatively, if the partition to which the client is joined a
majority partition, the client transitions to the client state 508
and background discovery handshakes are deactivated at 520.
[0041] While the client is in the client state 506, it is
configured to receive updates from the master of the server cluster
to which it is joined and updates the stored network location data
and metadata of its associated directory instance. The client is
also configured to provide read-only access to that information to
entities that are local to the client cluster.
[0042] If background discovery handshakes are active while the
client is in the client state 506, a process of the client
periodically searches for another host and/or partition that may be
more suitable than the host and/or partition to which the client is
currently joined. If a more suitable host and/or partition is found
by the background discover process, the client transitions to the
rejoin state 504 at 522 to rejoin with the identified more suitable
host and/or partition (e.g., a master host of a majority partition
that is discovered while the client is connected to a master host
of a non-majority partition).
[0043] If the client in the client state 506 detects a node and/or
membership change of the host and/or partition to which it is
joined at 524, it rechecks if the partition is a majority partition
at 516.
[0044] If the client loses connectivity to the master host to which
it is joined at 526, the client attempts to failover to a backup
host of the master host at 528. If the client is successful, the
client returns to the client state 506 at 530. Alternatively, if
the client fails to switch over to a backup host at 528, the client
transitions to the discover state 502 at 528.
[0045] In some examples, the remote directory client is configured
to continue offering access to its active directory information
after it has lost connection with the master of the current
partition. This may last until the client discovers a different
master and rejoins with it. Further, the remote directory client is
configured to be registered with only one server partition at a
time, even if it is able to reach multiple server partitions. In
some examples, the remote directory client is configured to operate
as a CMMDS client (e.g., based on VMWARE CMMDS architecture).
[0046] FIG. 6 is a flow chart illustrating a computerized method
600 for remotely mounting a shared data store as a remote data
store on a client cluster according to an embodiment. In some
examples, the method 600 is executed by or otherwise performed by
one or more components of a system such as systems 100, 200, and/or
300 of FIGS. 1, 2, and/or 3, respectively. A 602, a request is
received to mount a shared data store of a server cluster as a
remote data store of a client cluster. In some examples, the
request may be received from a controller component of the client
cluster in response to a need for data storage space that is not
available within the client cluster.
[0047] At 604, an access interface of the remote data store is
configured to be exposed to entities of the client cluster, wherein
the access interface is configured to receive data operations that
are in a local data store-based format. Such an interface is
configured to enable entities on the client cluster to interact
with the remote data store in the same manner as a local data store
of the client cluster, without having to alter any established
local storage semantics and ensuring that entities on the client
cluster need only be configured to interact with data stores in a
single, unified way.
[0048] At 606, if the server cluster meets the needs of the client
cluster, the process proceeds to 608. Alternatively, if the server
cluster does not meet the needs of the client cluster, another
available server cluster is selected at 610.
[0049] At 608, a control path interface (e.g., control path 260)
between the server cluster and the client cluster is established
and, at 612, network location data associated with the shared data
store of the server cluster is received via the established control
path interface. In some examples, the establishment of the control
path interface and transfer of network location data further
includes the storing of the received network location data in a
local instance on the client cluster (e.g., remote directory
instance 252) and maintenance of the local instance, such that
up-to-date network location data is maintained thereon. For
instance, the local instance may replicate or otherwise be
subscribed to a directory service on the server cluster such that
changes on the directory service are pushed to the local instance
as described herein.
[0050] At 614, based on the network location data, a data path
interface (e.g., data path 262) is established between the shared
data store of the server cluster and the remote data store of the
client cluster. Based on the established data path, the shared data
store is "mounted" as the remote data store on the client cluster,
such that entities of the client cluster are enabled to interact
with the shared data store as if it were a local data store on the
client cluster via the abstraction interface and established data
path interface. In some examples, the data path interface includes
and/or makes use of an object manager module stack, which may
include an object manager client (e.g., object manager client 254)
on the client cluster and an associated object manager (e.g.,
object manager 258) on the server cluster that are configured to
enable the performance of data operations on the shared data store
as described herein.
[0051] FIG. 7 is a flow chart illustrating a computerized method
700 for maintaining a remote directory instance on a client cluster
and routing data operation instructions to a shared data store
based on the remote directory instance according to an embodiment.
In some examples, the method 700 is executed by or otherwise
performed by one or more components of a system such as systems
100, 200, and/or 300 of FIGS. 1, 2, and/or 3, respectively. At 702,
a control path interface and data path interface are established
between the shared data store of the server cluster and the remote
data store of the client cluster. It should be understood that the
establishment of the control and data path interfaces may be
performed in substantially the same manner as described herein.
[0052] At 704, based on the established control path, a remote
directory instance of the remote data store of the client cluster
is configured to replicate the local directory service of the
shared data store of the server cluster. At 706, if new network
location data is received based on the replication, the remote
directory instance is updated with the new network location data at
710 and the process returns to 706 to detect for more new network
location data. Alternatively, if no new network location data is
received at 706, the process proceeds to 708.
[0053] If, at 708, data operation instructions for the remote data
store are received, the process proceeds to 712. Alternatively, if
no instructions for the remote data store are received, the process
returns to 706.
[0054] At 712, based on the network location data in the remote
directory instance, the data operation instructions are routed to
the shared data store and, at 714, the routed data operation
instructions are performed on the shared data store of the server
cluster. In some examples, results of the data operation
instructions (e.g., query results of a read operation or success
indicator associated with a write operation) may be returned to the
client cluster via the established data path interface.
Exemplary Operating Environment
[0055] Aspects of the disclosure are operable in both virtualized
and non-virtualized environments. In virtualized examples that
involve a hardware abstraction layer on top of a host computer
(e.g., server), the hardware abstraction layer allows multiple
containers to share the hardware resource. These containers,
isolated from each other, have at least a user application running
therein. The hardware abstraction layer thus provides benefits of
resource isolation and allocation among the containers. In some
examples, virtual machines (VMs) are used alternatively or in
addition to the containers, and hypervisors are used for the
hardware abstraction layer. In these examples, each VM generally
includes a guest operating system in which at least one application
runs.
[0056] For the container examples, it should be noted that the
disclosure applies to any form of container, such as containers not
including a guest operating system (OS), referred to herein as
"OS-less containers" (see, e.g., www.docker.com). OS-less
containers implement operating system-level virtualization, wherein
an abstraction layer is provided on top of the kernel of an
operating system on a host computer. The abstraction layer supports
multiple OS-less containers each including an application and its
dependencies. Each OS-less container runs as an isolated process in
user space on the host operating system and shares the kernel with
other containers. The OS-less container relies on the kernel's
functionality to make use of resource isolation (CPU, memory, block
I/O, network, etc.) and separate namespaces and to completely
isolate the application's view of the operating environments. By
using OS-less containers, resources may be isolated, services
restricted, and processes provisioned to have a private view of the
operating system with their own process ID space, file system
structure, and network interfaces. Multiple containers may share
the same kernel, but each container may be constrained to only use
a defined amount of resources such as CPU, memory and I/O.
[0057] The present disclosure is operable with a computing
apparatus according to an embodiment as a functional block diagram
800 in FIG. 8. In an embodiment, components of a computing
apparatus 818 may be implemented as a part of an electronic device
according to one or more embodiments described in this
specification. The computing apparatus 818 comprises one or more
processors 819 which may be microprocessors, controllers or any
other suitable type of processors for processing computer
executable instructions to control the operation of the electronic
device. Alternatively, or in addition, the processor 819 is any
technology capable of executing logic or instructions, such as a
hardcoded machine. Platform software comprising an operating system
820 or any other suitable platform software may be provided on the
apparatus 818 to enable application software 821 to be executed on
the device. According to an embodiment, mounting a shared data
store on a server cluster for use as a remote data store on a
client cluster as described herein may be accomplished by software,
hardware, and/or firmware.
[0058] Computer executable instructions may be provided using any
computer-readable media that are accessible by the computing
apparatus 818. Computer-readable media may include, for example,
computer storage media such as a memory 822 and communications
media. Computer storage media, such as a memory 822, include
volatile and non-volatile, removable and non-removable media
implemented in any method or technology for storage of information
such as computer readable instructions, data structures, program
modules or the like. Computer storage media include, but are not
limited to, RAM, ROM, EPROM, EEPROM, persistent memory, phase
change memory, flash memory or other memory technology, CD-ROM,
digital versatile disks (DVD) or other optical storage, magnetic
cassettes, magnetic tape, magnetic disk storage, shingled disk
storage or other magnetic storage devices, or any other
non-transmission medium that can be used to store information for
access by a computing apparatus. In contrast, communication media
may embody computer readable instructions, data structures, program
modules, or the like in a modulated data signal, such as a carrier
wave, or other transport mechanism. As defined herein, computer
storage media do not include communication media. Therefore, a
computer storage medium should not be interpreted to be a
propagating signal per se. Propagated signals per se are not
examples of computer storage media. Although the computer storage
medium (the memory 822) is shown within the computing apparatus
818, it will be appreciated by a person skilled in the art, that
the storage may be distributed or located remotely and accessed via
a network or other communication link (e.g. using a communication
interface 823).
[0059] The computing apparatus 818 may comprise an input/output
controller 824 configured to output information to one or more
output devices 825, for example a display or a speaker, which may
be separate from or integral to the electronic device. The
input/output controller 824 may also be configured to receive and
process an input from one or more input devices 826, for example, a
keyboard, a microphone or a touchpad. In one embodiment, the output
device 825 may also act as the input device. An example of such a
device may be a touch sensitive display. The input/output
controller 824 may also output data to devices other than the
output device, e.g. a locally connected printing device. In some
embodiments, a user may provide input to the input device(s) 826
and/or receive output from the output device(s) 825.
[0060] The functionality described herein can be performed, at
least in part, by one or more hardware logic components. According
to an embodiment, the computing apparatus 818 is configured by the
program code when executed by the processor 819 to execute the
embodiments of the operations and functionality described.
Alternatively, or in addition, the functionality described herein
can be performed, at least in part, by one or more hardware logic
components. For example, and without limitation, illustrative types
of hardware logic components that can be used include
Field-programmable Gate Arrays (FPGAs), Application-specific
Integrated Circuits (ASICs), Program-specific Standard Products
(ASSPs), System-on-a-chip systems (SOCs), Complex Programmable
Logic Devices (CPLDs), Graphics Processing Units (GPUs).
[0061] At least a portion of the functionality of the various
elements in the figures may be performed by other elements in the
figures, or an entity (e.g., processor, web service, server,
application program, computing device, etc.) not shown in the
figures.
[0062] Although described in connection with an exemplary computing
system environment, examples of the disclosure are capable of
implementation with numerous other general purpose or special
purpose computing system environments, configurations, or
devices.
[0063] Examples of well-known computing systems, environments,
and/or configurations that may be suitable for use with aspects of
the disclosure include, but are not limited to, mobile or portable
computing devices (e.g., smartphones), personal computers, server
computers, hand-held (e.g., tablet) or laptop devices,
multiprocessor systems, gaming consoles or controllers,
microprocessor-based systems, set top boxes, programmable consumer
electronics, mobile telephones, mobile computing and/or
communication devices in wearable or accessory form factors (e.g.,
watches, glasses, headsets, or earphones), network PCs,
minicomputers, mainframe computers, distributed computing
environments that include any of the above systems or devices, and
the like. In general, the disclosure is operable with any device
with processing capability such that it can execute instructions
such as those described herein. Such systems or devices may accept
input from the user in any way, including from input devices such
as a keyboard or pointing device, via gesture input, proximity
input (such as by hovering), and/or via voice input.
[0064] Examples of the disclosure may be described in the general
context of computer-executable instructions, such as program
modules, executed by one or more computers or other devices in
software, firmware, hardware, or a combination thereof. The
computer-executable instructions may be organized into one or more
computer-executable components or modules. Generally, program
modules include, but are not limited to, routines, programs,
objects, components, and data structures that perform particular
tasks or implement particular abstract data types. Aspects of the
disclosure may be implemented with any number and organization of
such components or modules. For example, aspects of the disclosure
are not limited to the specific computer-executable instructions or
the specific components or modules illustrated in the figures and
described herein. Other examples of the disclosure may include
different computer-executable instructions or components having
more or less functionality than illustrated and described
herein.
[0065] In examples involving a general-purpose computer, aspects of
the disclosure transform the general-purpose computer into a
special-purpose computing device when configured to execute the
instructions described herein.
[0066] An example system for remotely mounting a shared data store
as a remote data store on a client cluster comprising: at least one
processor of the client cluster; and at least one memory comprising
computer program code, the at least one memory and the computer
program code configured to, with the at least one processor, cause
the at least one processor to: receive a request to mount the
shared data store of a server cluster as a remote data store of the
client cluster, wherein the server cluster is remotely located
across a network from the client cluster; configure an abstraction
interface of the remote data store to be exposed to entities of the
client cluster, wherein the abstraction interface is configured to
receive data operations that are in a local data store-based
format; establish a control path interface between the server
cluster and the client cluster; receive network location data
associated with the shared data store of the server cluster via the
established control path interface; and based on the network
location data, establish a data path interface between the shared
data store of the server cluster and the remote data store on the
client cluster, whereby the shared data store of the server cluster
is mounted as the remote data store of the client cluster such that
data operations directed to the abstraction interface of the remote
data store of the client cluster are routed to the shared data
store of the server cluster via the established data path
interface.
[0067] A computerized method for remotely mounting a shared data
store as a remote data store on a client cluster comprises:
receiving, by a processor of the client cluster, a request to mount
the shared data store of a server cluster as a remote data store of
the client cluster, wherein the server cluster is remotely located
across a network from the client cluster; configuring, by the
processor, an abstraction interface of the remote data store to be
exposed to entities of the client cluster, wherein the abstraction
interface is configured to receive data operations that are in a
local data store-based format; establishing, by the processor, a
control path interface between the server cluster and the client
cluster; receiving, by the processor, network location data
associated with the shared data store of the server cluster via the
established control path interface; and based on the network
location data, establishing, by the processor, a data path
interface between the shared data store of the server cluster and
the remote data store on the client cluster, whereby the shared
data store of the server cluster is mounted as the remote data
store of the client cluster such that data operations directed to
the abstraction interface of the remote data store of the client
cluster are routed to the shared data store of the server cluster
via the established data path interface.
[0068] One or more non-transitory computer storage media having
computer-executable instructions for remotely mounting a shared
data store as a remote data store on a client cluster, upon
execution by a processor, cause the processor to at least: receive
a request to mount the shared data store of a server cluster as a
remote data store of the client cluster, wherein the server cluster
is remotely located across a network from the client cluster;
configure an abstraction interface of the remote data store to be
exposed to entities of the client cluster, wherein the abstraction
interface is configured to receive data operations that are in a
local data store-based format; establish a control path interface
between the server cluster and the client cluster; receive network
location data associated with the shared data store of the server
cluster via the established control path interface; and based on
the network location data, establish a data path interface between
the shared data store of the server cluster and the remote data
store on the client cluster, whereby the shared data store of the
server cluster is mounted as the remote data store of the client
cluster such that data operations directed to the abstraction
interface of the remote data store of the client cluster are routed
to the shared data store of the server cluster via the established
data path interface.
[0069] Alternatively, or in addition to the other examples
described herein, examples include any combination of the
following: [0070] further comprising: receiving, by the processor,
instructions to perform a data operation on the remote data store
of the client cluster from an entity in the client cluster via the
abstraction interface; and routing, by the processor, the
instructions to the shared data store of the server cluster based
on the established data path interface; wherein the server cluster
is configured to perform the data operation in the shared data
store based on the routed instructions. [0071] wherein establishing
the control path interface includes instantiating a local directory
copy on the client cluster associated with a data store directory
of the server cluster; wherein transferring the network location
data includes populating the local directory copy with network
location data of the data store directory of the server cluster
such that the network location data of the data store directory of
the server cluster is replicated in the local directory copy; and
wherein the server cluster is configured to push changes made to
the data store directory to the client cluster based on the
replication and the client cluster is configured to update the
local directory copy with the pushed changes. [0072] wherein the
abstraction interface of the remote data store is configured to
receive data operations formatted for compatibility with file-based
data storage from entities at a user level of the client cluster
and to convert received data operations into operations formatted
for compatibility with object based data storage for use with the
remote data store at a kernel level of the client cluster. [0073]
further comprising: identifying the server cluster with which to
establish the control path interface from a plurality of available
server clusters with shared data stores; wherein establishing the
control path interface between the identified server cluster and
the client cluster is based on determining that the identified
server cluster includes a shared data store that satisfies a data
capacity requirement of the client cluster. [0074] wherein
establishing the data path interface includes: instantiating an
object manager client associated with the remote data store;
identifying a network location of an object manager entity
associated with the shared data store of the server cluster based
on the received network location data; linking the object manager
client with the object manager entity based on the identified
network location via a connection across the network; requesting,
by the object manager client, data store layout data associated
with the shared data store from the object manager entity;
receiving, by the object manager client, the data store layout data
associated with the shared data store; and establishing a data path
interface between the object manager client and at least one
portion of the shared data store based on the received data store
layout data. [0075] wherein the data store of the server cluster is
mounted as a remote data store for a plurality of client
clusters.
[0076] Any range or device value given herein may be extended or
altered without losing the effect sought, as will be apparent to
the skilled person.
[0077] While no personally identifiable information is tracked by
aspects of the disclosure, examples have been described with
reference to data monitored and/or collected from the users. In
some examples, notice may be provided to the users of the
collection of the data (e.g., via a dialog box or preference
setting) and users are given the opportunity to give or deny
consent for the monitoring and/or collection. The consent may take
the form of opt-in consent or opt-out consent.
[0078] Although the subject matter has been described in language
specific to structural features and/or methodological acts, it is
to be understood that the subject matter defined in the appended
claims is not necessarily limited to the specific features or acts
described above. Rather, the specific features and acts described
above are disclosed as example forms of implementing the
claims.
[0079] It will be understood that the benefits and advantages
described above may relate to one embodiment or may relate to
several embodiments. The embodiments are not limited to those that
solve any or all of the stated problems or those that have any or
all of the stated benefits and advantages. It will further be
understood that reference to `an` item refers to one or more of
those items.
[0080] The embodiments illustrated and described herein as well as
embodiments not specifically described herein but within the scope
of aspects of the claims constitute exemplary means for receiving,
by a processor of the client cluster, a request to mount the shared
data store of a server cluster as a remote data store of the client
cluster, wherein the server cluster is remotely located across a
network from the client cluster; exemplary means for configuring,
by the processor, an abstraction interface of the remote data store
to be exposed to entities of the client cluster, wherein the
abstraction interface is configured to receive data operations that
are in a local data store-based format; exemplary means for
establishing, by the processor, a control path interface between
the server cluster and the client cluster; exemplary means for
receiving, by the processor, network location data associated with
the shared data store of the server cluster via the established
control path interface; and, based on the network location data,
exemplary means for establishing, by the processor, a data path
interface between the shared data store of the server cluster and
the remote data store on the client cluster, whereby the shared
data store of the server cluster is mounted as the remote data
store of the client cluster such that data operations directed to
the abstraction interface of the remote data store of the client
cluster are routed to the shared data store of the server cluster
via the established data path interface.
[0081] The term "comprising" is used in this specification to mean
including the feature(s) or act(s) followed thereafter, without
excluding the presence of one or more additional features or
acts.
[0082] In some examples, the operations illustrated in the figures
may be implemented as software instructions encoded on a computer
readable medium, in hardware programmed or designed to perform the
operations, or both. For example, aspects of the disclosure may be
implemented as a system on a chip or other circuitry including a
plurality of interconnected, electrically conductive elements.
[0083] The order of execution or performance of the operations in
examples of the disclosure illustrated and described herein is not
essential, unless otherwise specified. That is, the operations may
be performed in any order, unless otherwise specified, and examples
of the disclosure may include additional or fewer operations than
those disclosed herein. For example, it is contemplated that
executing or performing a particular operation before,
contemporaneously with, or after another operation is within the
scope of aspects of the disclosure.
[0084] When introducing elements of aspects of the disclosure or
the examples thereof, the articles "a," "an," "the," and "said" are
intended to mean that there are one or more of the elements. The
terms "comprising," "including," and "having" are intended to be
inclusive and mean that there may be additional elements other than
the listed elements. The term "exemplary" is intended to mean "an
example of" The phrase "one or more of the following: A, B, and C"
means "at least one of A and/or at least one of B and/or at least
one of C."
[0085] Having described aspects of the disclosure in detail, it
will be apparent that modifications and variations are possible
without departing from the scope of aspects of the disclosure as
defined in the appended claims. As various changes could be made in
the above constructions, products, and methods without departing
from the scope of aspects of the disclosure, it is intended that
all matter contained in the above description and shown in the
accompanying drawings shall be interpreted as illustrative and not
in a limiting sense.
* * * * *
References