Enterprise File System (EFS)
EFS is an open-source, Apache-licensed Linux/Unix-based software product that provides software distribution and change control for heterogeneous clients using distributed filesystems (currently NFSv3, with plans for supporting both NFSv4 and OpenAFS). EFS was designed to support extremely large, global enterprises, but can be scaled down for smaller environments as well.
- A special-purpose Unix global file system
- A collaborative mechanism for developers to quickly and easily share and deploy software
- A system for tracking releases of software
Overall Reduction in: Time, Resources and Budget
EFS Benefits
EFS is a client/server software product which implements a versionized namespace for application deployment in a distributed filesystem (currently NFSv3, with plans to support NFSv4 and OpenAFS). The EFS namespace makes it feasible to deploy multiple versions of the same application side by side, each with its own distinct set of dependencies.
- Less time spent deploying software to internal clients
- If the software is in EFS any client attached to EFS will have access to all core applications available
- Recovery is quick and relatively painless
- Roll-back of software is done in near-seconds instead of hours or days
EFS or Enterprise File System is a suite of Perl-based commands to help deploy, distributed and maintain versioning of software releases in the UNIX environment. These commands structure your file system to allow ease of deployment and, as a byproduct, standardize your environment. It even abstracts the OS from the end user so that file locations are common across different UNIX flavors
In addition to the Perl layer, EFS infrastructure also consits of an NFS namespace and a database system (Oracle or MySQL are the supported flavors as of the time of this writing)
EFS is not:
- a software repository like Source Forge or Download.com
- a place to store source code for revision control purposes, like CVS, Subversion, or the like.
- just another NFS variant. EFS leverages NFS under the hood, but it's a suite of functionality layered on top of NFS
Introduction to the Basic Structure of EFS
An “EFS Cell” is the building block of the global EFS environment. It is simply the NAS filer (or filers) and the NFS clients that mount the /efs file systems from them, as a single administrative subdomain of the global environment. This cell can have the celltype of either DEV (for development and QA/UAT testing) or PROD (production). There is at most one cell per distinct data center per celltype. A single cell, though, can support multiple data centers.
EFS has 2 main namespaces: “/efs/dev” (read/write) for development, and “/efs/dist” (read only) for distributed code. The DEV celltype supports both /efs/dev and /efs/dist (for UAT and QA testing). The PROD celltype supports only /efs/dist.
A NAS filer containing the EFS data is called an EFS “Cell.” This cell consists of every part of EFS’s infrastructure in a single location, including storage, EFS management servers and caches. The collection of cells within a region is referred to as a “Regional Cell.” When any UNIX server is connected to EFS, they access the EFS Namespace.
Each regional cell may contain the EFS DEV or EFS PROD environments or both.
- A NAS filer containing the EFS data is called an EFS “CELL”
- A cell consists of every part of EFS’s infrastructure in a single location
- The collection of cells within a region is referred to as a “CELL SET” or “REGIONAL CELL”
There are 2 environments in EFS
dev
The Dev environment supports /efs/dev (read-write) and /efs/dist( read-only , simulating PROD used for testing debugging QA )
prod
The Prod environment contains a “locally” form of /efs/dist only
Connecting to EFS
To connect a client to EFS, a simple boot script is installed on the client machine. This script makes the static NFS mount points necessary to make the /efs/dist, and optionally /efs/dev, file systems available on the client.
EFS Components
EFS is built using NAS Filers and the NFS Protocol. The original Morgan Stanley project was based on AFS, but Merrill Lynch was uninterested in this technology. The NAS Filers are abstracted from clients originally by using Acopia file switches, but eventually by using Linux automounter technology for the DEV environment and NAS’ FlexCache technology for PROD.
There are two components to EFS: (1) the File System and (2) the Management Utility. The File System is the EFS namespace - NFS mounted on EFS clients. The Management Utility is the EFS Command Line Utility (CLI) for creating and managing projects in EFS.
EFS Commands
EFS is managed from a core Perl Library that contains most application logic. The library is accessed via a simple command line interface (CLI), via a client/server architecture which centralizes all privileged EFS commands to limited set of administrative servers. The basic structure of an EFS command is as follows: “efs action object [arguments]”action is an operation, (e.g. create, define, destroy, etc.) object is what the operation acts on, (e.g. business, metaproj, release, cell, etc.) arguments are the additional strings of information needed to complete the command
Developers and EFS Operations each run different commands to complete tasks in the EFS environment.
Example:-
efs create release wlm xcat 2.6.6-01
efs create install wlm xcat 2.6.6-01 common
Reference:-
http://openefs.org/
Google Search
EFS is an open-source, Apache-licensed Linux/Unix-based software product that provides software distribution and change control for heterogeneous clients using distributed filesystems (currently NFSv3, with plans for supporting both NFSv4 and OpenAFS). EFS was designed to support extremely large, global enterprises, but can be scaled down for smaller environments as well.
- A special-purpose Unix global file system
- A collaborative mechanism for developers to quickly and easily share and deploy software
- A system for tracking releases of software
Overall Reduction in: Time, Resources and Budget
EFS Benefits
EFS is a client/server software product which implements a versionized namespace for application deployment in a distributed filesystem (currently NFSv3, with plans to support NFSv4 and OpenAFS). The EFS namespace makes it feasible to deploy multiple versions of the same application side by side, each with its own distinct set of dependencies.
- Less time spent deploying software to internal clients
- If the software is in EFS any client attached to EFS will have access to all core applications available
- Recovery is quick and relatively painless
- Roll-back of software is done in near-seconds instead of hours or days
EFS or Enterprise File System is a suite of Perl-based commands to help deploy, distributed and maintain versioning of software releases in the UNIX environment. These commands structure your file system to allow ease of deployment and, as a byproduct, standardize your environment. It even abstracts the OS from the end user so that file locations are common across different UNIX flavors
In addition to the Perl layer, EFS infrastructure also consits of an NFS namespace and a database system (Oracle or MySQL are the supported flavors as of the time of this writing)
EFS is not:
- a software repository like Source Forge or Download.com
- a place to store source code for revision control purposes, like CVS, Subversion, or the like.
- just another NFS variant. EFS leverages NFS under the hood, but it's a suite of functionality layered on top of NFS
Introduction to the Basic Structure of EFS
An “EFS Cell” is the building block of the global EFS environment. It is simply the NAS filer (or filers) and the NFS clients that mount the /efs file systems from them, as a single administrative subdomain of the global environment. This cell can have the celltype of either DEV (for development and QA/UAT testing) or PROD (production). There is at most one cell per distinct data center per celltype. A single cell, though, can support multiple data centers.
EFS has 2 main namespaces: “/efs/dev” (read/write) for development, and “/efs/dist” (read only) for distributed code. The DEV celltype supports both /efs/dev and /efs/dist (for UAT and QA testing). The PROD celltype supports only /efs/dist.
A NAS filer containing the EFS data is called an EFS “Cell.” This cell consists of every part of EFS’s infrastructure in a single location, including storage, EFS management servers and caches. The collection of cells within a region is referred to as a “Regional Cell.” When any UNIX server is connected to EFS, they access the EFS Namespace.
Each regional cell may contain the EFS DEV or EFS PROD environments or both.
- A NAS filer containing the EFS data is called an EFS “CELL”
- A cell consists of every part of EFS’s infrastructure in a single location
- The collection of cells within a region is referred to as a “CELL SET” or “REGIONAL CELL”
There are 2 environments in EFS
dev
The Dev environment supports /efs/dev (read-write) and /efs/dist( read-only , simulating PROD used for testing debugging QA )
prod
The Prod environment contains a “locally” form of /efs/dist only
Connecting to EFS
To connect a client to EFS, a simple boot script is installed on the client machine. This script makes the static NFS mount points necessary to make the /efs/dist, and optionally /efs/dev, file systems available on the client.
EFS Components
EFS is built using NAS Filers and the NFS Protocol. The original Morgan Stanley project was based on AFS, but Merrill Lynch was uninterested in this technology. The NAS Filers are abstracted from clients originally by using Acopia file switches, but eventually by using Linux automounter technology for the DEV environment and NAS’ FlexCache technology for PROD.
There are two components to EFS: (1) the File System and (2) the Management Utility. The File System is the EFS namespace - NFS mounted on EFS clients. The Management Utility is the EFS Command Line Utility (CLI) for creating and managing projects in EFS.
EFS Commands
EFS is managed from a core Perl Library that contains most application logic. The library is accessed via a simple command line interface (CLI), via a client/server architecture which centralizes all privileged EFS commands to limited set of administrative servers. The basic structure of an EFS command is as follows: “efs action object [arguments]”action is an operation, (e.g. create, define, destroy, etc.) object is what the operation acts on, (e.g. business, metaproj, release, cell, etc.) arguments are the additional strings of information needed to complete the command
Developers and EFS Operations each run different commands to complete tasks in the EFS environment.
Example:-
efs create release wlm xcat 2.6.6-01
efs create install wlm xcat 2.6.6-01 common
Reference:-
http://openefs.org/
Google Search
No comments:
Post a Comment