Access Keys:
Skip to content (Access Key - 0)

Community


caBIG caGrid 1.2 Production Grid


Overview

The cancer Biomedical Informatics Grid, or caBIG is an initiative of the National Cancer Institute, part of the National Institutes of Health.

caBIG is a voluntary virtual informatics infrastructure that connects data, research tools, scientists, and organizations to leverage their combined strengths and expertise in an open federated environment with widely accepted standards and shared tools. The underlying service oriented infrastructure that supports caBIG is referred to as caGrid. Driven primarily by scientific use cases from the cancer research community, caGrid provides the core enabling infrastructure necessary to compose the Grid of caBIG. It provides the technology that enables collaborating institutions to share information and analytical resources efficiently and securely, while also allowing investigators to easily contribute to and leverage the resources of a national-scale, multi-institutional environment.

Current Version


We are pleased to announce that the transition to caGrid 1.2 infrastructure has been completed. The caGrid 0.5 infrastructure and associated tools have been desupported as of January 1, 2008. All caGrid services and tools should use the caGrid 1.2 production infrastructure.

If you have any questions, please do not hesitate to request support.

Service Addresses


The design of caGrid is such that one needn't hardcode the addresses of services, as each running service registers itself to the Index Service. Registered services can then be discovered programmatically. In this sense, the Index Service is really the only service that a "well known address" is needed. However, in some cases it may be useful to know the address of core services. The NCI maintained production deployment of the core caGrid infrastructure services are:

The production grid can also be observed on the caGrid Portal.

Production Grid Hardware


Services for the NCI Production grid are hosted on multiple servers:
Physical Machines|| OS || CPU || RAM || Disk || Services ||

RHEL4 2 x Intel 3.8 GHz 12 GB 2 x 146 GB, 2 x 72 GB Dorian, syncGTS
RHEL4 2 x Intel 3.8 GHz 12 GB 2 x 146 GB, 2 x 72 GB Authentication Service, CDS, syncGTS
RHEL4 4 x AMD 2.8 GHz Dual Core 64 GB
VMWare ESX 3.02 VMHost #1
RHEL4 4 x AMD 2.8 GHz Dual Core 64 GB
VMWare ESX 3.02 VMHost #2
RHEL4 4 x AMD 2.8 GHz Dual Core 64 GB
VMWare ESX 3.02 VMHost #3

Virtual Machines: hosted on a 3-way ESX cluster (VMHost #1-3 above)|| OS || CPU || RAM || Disk || Services ||

RHEL4 1 VM CPU 2 GB 20 GB VM HD Index Service, syncGTS
RHEL4 1 VM CPU 1 GB 20 GB VM HD GME, caDSR, EVS, syncGTS
RHEL4 1 VM CPU 1 GB 20 GB VM HD GTS Master, syncGTS
RHEL4 1 VM CPU 1 GB 20 GB VM HD GTS Slave, syncGTS
RHEL4 1 VM CPU 4 GB 20 GB VM HD caGrid Browser, caGrid Portal Web, syncGTS
RHEL4 1 VM CPU .75 GB 20 GB VM HD FQP, Workflow, syncGTS
RHEL4 1 VM CPU .75 GB 20 GB VM HD Grid Grouper, syncGTS
  • A note about virtual machines: Several services require synchronization system clocks (due to time-based operations, such as the Index Service, or time-based certificate constraints, such as Dorian or the Authentication Service). In some deployments of Virtual Machines, time drift has been observed under a moderate load. For this reason, Dorian and Authentication Service were not hosted on virtual machines in the production environment, though we have successfully deployed them on Virtual Machines in other deployments.
Last edited by
Justin Permar (1162 days ago) , ...
Adaptavist Theme Builder Powered by Atlassian Confluence