Sybase Data Federation is enabled via Data Federation servers that provide Enterprise Information Integration (EII) capabilities. These servers simplify provisioning, access, and integration of distributed data for one group, or across the extended enterprise.You can integrate relational data, XML documents, files, and application data across departments, locations, and companies, and allow access to authorized users via a number of protocols and interfaces including transparent file access, ODBC, JDBC, and SOAP.
Before installing Sybase Data Federation, determine how to deploy Data Federation subcomponents in your environment. Decide the number of Data Federation servers required in your domain, and the machines on which these servers will run.
Use the DI Suite installer to install the Sybase Data Federation subcomponents. The Sybase Data Federation domain can consist of one or more servers that together implement the data catalog and provide data integration framework and its provisioning and access services.
Basic Data Federation domain
A basic Data Federation domain can contain one or more grid servers, with one serving as the grid domain controller (GDC).
Grid server – hosts the data catalog, provides authorization services for clients requesting data access, serves files shared from the local file system, caches data to improve performance, and runs data services, database operations, and queries.
Grid domain controller (GDC) – the grid server on which a Data Federation domain is initially started. The grid domain controller has all the functionality of a grid server. A Data Federation domain must have at least one grid domain controller.
In a Data Federation domain that is configured for failover, there are two GDCs: a primary and a secondary. The secondary GDC is a hot standby that handles requests when the primary GDC cannot be reached.
NFS or Windows file access
Data grid access server (DGAS) – provides high-performance caching and makes data catalogs and their contents available to Network File System (NFS) and Common Internet File System (CIFS) clients in a secure fashion.
Extended file sharing
Share server – makes selected data stored in local file systems visible in the data catalog. Share servers are responsible for file I/O.
Interconnecting domains
Firewall proxy server – allows Data Federation domains on opposite sides of a firewall to communicate securely with one another so that users of each domain can access data in the other.
Data Federation domains can be accessed by a number of different clients. In some cases, clients require no Sybase software installed on their machines. This category includes transparent file access clients that access files in the data catalog via NFS or CIFS and Web service clients that access Avaki via SOAP calls. Clients that require some Sybase software installed include ODBC or JDBC clients and machines that are used for running the Avaki command line interface (CLI) client.
Avaki Client
Command-line Client – enables you to perform all data federation and administration tasks using the command line interface.
To use Sybase Data Federation development capabilities, install Sybase WorkSpace. Sybase WorkSpace is packaged separately from DI Suite. You must use the installer provided with Sybase WorkSpace to install this development tool for DI Suite.
Consider the following installation guidelines to help you plan your Data Federation domain. These are general guidelines that do not cover all possibilities. Planning a Data Federation domain is a complex activity that must be performed in consultation with a Sybase deployment architect.
Some data grids are used primarily for file access, some primarily for database access, and some are used for both. Based on the usage scenarios for your data grid, choose the appropriate servers to deploy.
The GDC functions as the first grid server in the domain. Add more grid servers to accommodate more file data, more data services, more concurrent users, or additional sites that require administrative autonomy.
If you include a secondary GDC in your domain, install the primary and secondary GDCs on different machines.
If you want a secondary GDC in your Data Federation domain, set it up after you set up the primary GDC, but before you set up the other Avaki servers in the domain. If you set up other servers before the secondary GDC, the Avaki failover mechanism does not function properly.
Install one grid server per machine. Sybase recommends that you use a dedicated machine for each grid server. A dedicated machine is particularly important for a GDC.
The location of a grid server that performs caching can affect network loads and the performance and response time experienced by users and applications that consume the cached data. In choosing a location, consider whether the caching will be primarily local or primarily remote. A grid server performing local caching is best located close to the data sources it uses. A grid server performing remote caching is best located close to the consumers of the cached data.
Each grid server can be associated with several share servers.
For best performance, install each share server close to its data—if possible, on the same physical machine. A grid server that functions as a share server should also be close to its data, but this consideration must be balanced against the needs of other services the grid server provides, such as caching and data service execution and the desirability of installing grid servers on dedicated machines.
You can install multiple share servers on one machine; the benefit of this arrangement is to limit the I/O between share server processes and local directories.
Figure 8-3 shows an example deployment architecture of a Data Federation domain with primary and secondary grid domain controllers, grid servers, share servers, a firewall proxy server, and a data grid access server deployed. Users and applications can access relational data and Web Services via Avaki services configured on the grid servers and files via the data grid access server using NFS or CIFS (Windows) clients.