Tags:
, view all tags

1 WMProxy Service

1.1 About WMProxy

WMProxy is a new component to access the EMI Workload Management System (WMS).

The need of such a component, besides adhering to the emerging design methodology called Service Oriented Architecture (SOA), is to improve the performance of existing similar components, to handle more efficiently a large number of requests for job submission and control and also to provide additional features.

The WMProxy is implemented as a Web service. The Web is considered a successful technology mostly because of its simplicity and ubiquity. A Web service allows us to take advantage of the benefits of the Web, not only to provide information, but also to offer services to a greater community of possible users.

Since the European Middleware Initiative (EMI) Middleware is a composition of Grid services provided by different vendors and/or operated by different organizations, the Web services technology is a powerful means to achieve service interoperability and allow easier compliance with emerging standards such as Open Grid Services Architecture (OGSA) and Web Services Resource Framework (WSRF).

1.2 Client configuration

C++ WMProxy client commands behavior may be configured by editing a proper configuration file. Here follow the steps needed to properly configure file location on client side:

  1. For each supported Virtual Organisation a directory must be created, with the following name:
    /etc/glite-wms/<vo name-lowercase>
    (e.g. for dteam /etc/glite-wms/dteam)
  2. Files installation:
    org.glite.wms.client
    (version > 3.1.9) installs a template file in the following location:
    /etc/vo_template/glite_wmsui.conf.template
    This file should be copied with the name "glite_wmsui.conf" in each directory created in step 1)

    for backward compatibility (version <= 3.1.9) old configuration file name approach is still accepted
    /etc/vo_template/glite_wms.conf
    This file should be copied with the name "glite_wms.conf" in each directory created in step 1)
  3. Edit the configuration files, e.g.:
    /etc/glite-wms/dteam/glite_wms.conf
    and check if desired parameters are correctly set, e.g.:
    [
          WMProxyEndPoints = {"https://ghemon.cnaf.infn.it:7443/glite_wms_wmproxy_server"};
          ErrorStorage = "/var/tmp"; 
          OutputStorage= "/tmp";
          ListenerStorage = "/tmp";
          VirtualOrganisation = "dteam";
          JdlDefaultAttributes=[
                  RetryCount = 3;
                  ShallowRetryCount = 3;
                  rank =  -other.GlueCEStateEstimatedResponseTime;
                  requirements = other.GlueCEStateStatus == "Production" ;
                  myCustomizedAttribute = "foo";
                  SignificantAttributes={"rank","requirements","fuzzyrank"};
                  ]
          ]
    For backward compatibility (version <= 3.1.9), WmsClient section of the configuration file will contain above attributes
  4. Configuration file attributes description
    A brief summary of all supported attributes for the configuration file follows.
    WMProxyEndPoints
    : list of endpoints URL of the WMProxy to contact.
    ErrorStorage: path of the directory where the UI creates log files.
    OutputStorage: path of the directory where the job OutputSandbox files are stored if not specified by the user through commands options.
    ListenerStorage
    : path of the directory where are created the pipes where the glite_wms_console_shadow process saves the job standard streams for interactive jobs.
    VirtualOrganisation
    : the virtual organisation used to perform the operation
    JdlDefaultAttributes: (version >= 3.1.13) This is a classad attribute and allows the user specifying a set of attributes/values that will be automatically inserted in the submitting JDL
    For backward compatibility (since version < 3.1.13, JdlDefaultAttributes section not present) following attriubtes will be taken in consideration:
    Rank: default value for the ranking expression in the JDL.
    Requirements: default value for the requirements expression in the JDL (a further condition on the submitting requirements will be added)
    RetryCount: default value for the RetryCount attribute in the JDL.
    MyProxyServer: MyProxy server address. To be set only if proxy renewal has to be enabled for all requests.
    LBAddress: this attribute forces the WMProxy server to register jobs and/or log events to the specified LB.
  5. Configuration File Priority
    Attributes listed configuration file described in step 2) may be overridden by (in order of priority):

    --config option of WMProxy Client commands
    $HOME/.glite/<vo name>/glite_wmsclient.conf
    $GLITE_WMS_CLIENT_CONFIG

    Please note that the attributes not present in the customized file, yet listed in file described in step 2), are inherited by final configuration attributes. If the user does not want to inherit a specific attribute, he may assign a null/empty value (depending on the type).
    Please notice that default configuration files will be parsed anyway: default attributes will be taken in consideration when not found on customized configuration file.
  6. Other client configuration steps:
    • Make sure $GLOBUS_LOCATION/lib and $GLITE_LOCATION/lib are included in the LD_LIBRARY_PATH
    • Add $GLITE_LOCATION/bin to your PATH

1.3 Architecture

To adhere to the SOA model, WMProxy has been designed and implemented as a Simple Object Access Protocol (SOAP) Web service. The interface is described through the Web Service Description Language (WSDL). The WSDL file was written following the Web Services Interoperability Basic Profile (WS-I Basic Profile). This profile defines a set of Web Services specifications that promote interoperability. The WMProxy service runs in an Apache container extended with Fast CGI and Grid Site modules.
  • The Fast CGI module provides Common Gateway Interface (CGI) functionality with some other specific features. The most important advantage of Fast CGI is its performance and persistence. Fast CGI can be seen as a new implementation of CGI, designed to overcome CGI's performance problems. The major implementation differences are:
    • Fast CGI processes are persistent: Fast CGI applications are able to serve multiple requests
    • Application instances are spawned/killed dynamically according to demand
    • Fast CGI protocol multiplexes the environment information, standard input, output, and error over a single full-duplex connection.

WMProxy in its default configuration is run as a dynamic Fast CGI application in order to take full advantage of its capacity to accommodate request loads. However, it can be run in any of the available Fast CGI modalities. WMProxy is implemented as a single-threaded application thus ensuring more reliability and robustness than multi-threaded applications; thanks to the Fast CGI process manager the web server maintains a pool of processes that allow improving performances as generally done through multi-threaded application.

  • Grid Site provides a module extending the Apache webserver for use within Grid frameworks by adding support for Grid security credentials such as Grid Security Infrastructure (GSI) and Virtual Organization Membership Service (VOMS), and file transfer over HTTPS. It also provides a library for handling Grid Access Control Lists (GACL).
The Web Service hosting framework provided by Apache, Grid Site and gSOAP has allowed the development of the WMProxy service using the C++ language. The choice of the implementation language has been driven mostly by the need to re-use and integrate existing production-quality components and libraries. A further boost in this direction has been given by preliminary tests that have shown better performance for the couple C++/gSOAP in comparison with the most commonly used framework for the development of Web Services (e.g., Axis/Java). Last but not least the gSOAP interoperability with a variety of other SOAP implementations and toolkits that permitted the development of a service accessible from clients written in different programming language and running on any computer platform.

wmproxyintegration.gif

The integration of the WMProxy within the WMS is shown in Figure 1. WMProxy provides a core module performing validation, conversion, environment preparation and information logging for each incoming request, before delivering it to the Workload Manager (WM). WM is the core component of the WMS taking the appropriate actions to satisfy incoming requests. Communication between the WMProxy and the WM occurs through a thread-safe, file-system based queue. The LBProxy, which is used as a state storage of active jobs, is the only external service with which the WMProxy interacts. The LBProxy service provides an optimized access to the Logging and Bookkeeping Service (LB). Other relevant information about processed jobs/requests are stored in the local file system in a reserved area managed by the WMS.

1.4 Security, AuthN & AuthZ

Message exchange between client and server is performed with SOAP/HTTPS.

Authentication of the requesting user is done through the X.509 proxy certificate signed by a trusted Certification Authority (CA), which guarantees that the exposed public key is really owned by the user. The authentication process is handled by the Apache HTTP server by means of the SSL and Grid Site modules. The authenticated request together with information about the checked credential (e.g. expiration time, VOMS extensions), are then passed to WMProxy within the CGI environment. WMProxy does not need to directly manipulate Grid credentials in this phase.

Authorization is implemented through the Grid Access Control List (GACL) library, which is provided by Grid Site for manipulating Access Control List (ACL) files. Authorization can be either Fully Qualified Attribute Name (FQAN) (coarse-grained) or Distinguished Name (DN) based (fine-grained) according to the type of proxy presented by the client.

There are two authorization steps that are performed for an incoming request within the WMProxy:

  • Determine whether the requesting user is authorized to use the WMS services.
  • Determine whether the requesting user is either the owner of the job or has permissions to manage it. (This step is only performed for operations directly related to a given job)
User Mapping: when a user performs a request to the WMProxy service, he is mapped to a local user, which is needed to perform all filesystem operations related to single jobs. This mapping is done through LCMAPS module.

1.5 Credentials Delegation

1.5.1 Delegation Process

The delegation is the process used to transfer rights and privileges to another party. Since the WMProxy and the WMS when providing some services need to interact with other services, operating on behalf of the user, a delegation process is needed to transfer client proxy credentials to the server host. The delegation service is provided through a port type whose description is imported into the WMProxy WSDL file from the gLite common delegation WSDL file. Delegated credentials are uniquely identified by the association of the delegation identifier, provided by user, and the user’s DN within the credentials. Multiple delegations of the same proxy credential are allowed with different delegation identifiers; however, it is recommended to do it once at the beginning of the working session and reuse the same delegation identifier, as delegation process is generally time-consuming. The WMProxy holds a cache of the delegated proxies, which is purged periodically from the expired credentials; upon a submission request the service performs a mapping between the incoming job and a proxy in its cache according to the requesting user DN and the specified delegation identifier. From that point on, each operation performed for that job is done using the credential associated to it in this way.

delegationsequence.gif

1.5.2 Credentials Renewal

The User can store a long-lived certificate that can be used by the WMS in order to renew the lifetime of a standard user certificate proxy (usually valid only for 12 hours). Long-running jobs may run into this limit and fail due to expioration of user proxy. WMProxy can automatically request the registration for renewing the proxy certificate sent by the user. This is done through the attribute "MyProxyServer" inside the submitting JDL. When a Proxy Renewal Registration is requested for a certain Job, the WMProxy registers it to the proxy renewal. From that moment on, credentials for such jobs are granted by renewed certificate credentials. Actually all jobs that uses the same credentials links to only one renewed certificate.

-- FabioCapannini - 2011-11-04

Topic attachments
I Attachment Action SizeSorted descending Date Who Comment
GIFgif wmproxyintegration.gif manage 40.8 K 2011-11-15 - 10:55 FabioCapannini  
GIFgif delegationsequence.gif manage 4.2 K 2011-11-15 - 11:29 FabioCapannini  
Edit | Attach | PDF | History: r5 < r4 < r3 < r2 < r1 | Backlinks | Raw View | More topic actions...
Topic revision: r4 - 2011-11-15 - FabioCapannini
 
  • Edit
  • Attach
This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback