Distributed SpectroSERVER
Notice Cabletron Systems reserves the right to make changes in specifications and other information contained in this document without prior notice. The reader should in all cases consult Cabletron Systems to determine whether any such changes have been made. The hardware, firmware, or software described in this manual is subject to change without notice.
Restricted Rights Notice (Applicable to licenses to the United States Government only.) 1. Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013. Cabletron Systems, Inc., 35 Industrial Way, Rochester, New Hampshire 03866-5005. 2. (a) This computer software is submitted with restricted rights.
Contents Chapter 1 Overview Why Distributed SpectroSERVER? ................................................................................... 1-3 How to Implement Distributed SpectroSERVER ............................................................. 1-4 Distributed SpectroSERVER Terminology and Concepts ................................................ 1-5 Landscapes ................................................................................................................... 1-5 Landscape Map .....
Database Partitioning Files ........................................................................................ A-3 Preparing to Partition ................................................................................................. A-3 Partitioning the Database ........................................................................................... A-4 Performing Diagnostics on Your Converted Database............................................... A-7 Attributes To Be Converted ................
Chapter 1 Overview This chapter provides an overview of the necessities and advantages of implementing a distributed SpectroSERVER environment. A Distributed SpectroSERVER (DSS) environment allows you to divide SPECTRUM’s network management tasks among several SpectroSERVERS and provides an integrated user interface and integrated applications.
Figure 1-1.
Why Distributed SpectroSERVER? Why Distributed SpectroSERVER? Single management workstations are limited in their capacity to manage large networks. Imagine trying to manage all of the devices on the Internet with a single management workstation. When dealing with networks this large, a “divide and conquer” method is used which is just another name for distributed network management.
How to Implement Distributed SpectroSERVER SpectroSERVER Redundancy With Distributed SpectroSERVER, it becomes possible to set up redundancy between SpectroSERVERs. A secondary SpectroSERVER can be provided as redundant backup for a primary SpectroSERVER. Network management would continue even if the workstation running the primary SpectroSERVER fails. By simply reloading a "Landscape" database on a secondary SpectroSERVER, the network manager is protected against failures.
Distributed SpectroSERVER Terminology and Concepts Distributed SpectroSERVER Terminology and Concepts This section provides descriptions of the terminology and concepts used when discussing a Distributed SpectroSERVER environment. Landscapes A landscape model is a SpectroGRAPH container model that provides a means of connecting to other SpectroSERVERs in the landscape map through the SPECTRUM user interface.
Distributed SpectroSERVER Terminology and Concepts Landscape Map Figure 1-2.
Distributed SpectroSERVER Terminology and Concepts Modeling Catalog Modeling Catalog A modeling catalog is a set of templates (model types, relations, etc.) installed on a particular SpectroSERVER that can be used in creating models. The set of models created through these templates make up that SpectroSERVER’s landscape. When you model multiple landscapes using Distributed SpectroSERVER, each landscape must contain identical modeling catalogs.
Distributed SpectroSERVER Terminology and Concepts User Model NOTE Overview 1-8 Deleting a user model only deletes the model in that landscape. Duplicate user models on other SpectroSERVERs in the landscape map must be deleted manually.
Chapter 2 Setting up a Distributed SpectroSERVER Environment This chapter describes procedures for setting up a distributed SPECTRUM environment. It also discusses processd, a SPECTRUM control process. For a large network consisting of several subnets connected via wide area links and covering a large geographic area, the use of multiple landscapes using DSS is recommended.
Network Partitioning Assigning Landscape Handles • If IP address boundaries are already established, and they do not provide a means of separating landscapes, then your second choice is to establish unique community names to differentiate devices in each landscape. This method requires more effort, since these names must be added to each device’s community names table. • Your last choice is to create partitions according to some other parameter (time-zone, state, etc.
Network Partitioning Changing Landscape Handles The new landscape handle can be specified in either decimal or hexadecimal notation. If you use decimal notation, the lh_set utility converts your entry into a hexidecimal landscape handle. ! CAUTION You must run the lh_set utility BEFORE you run SpectroSERVER for the first time. If you run SpectroSERVER before running lh_set, SPECTRUM assigns a default landscape handle that is the same whenever and wherever it is assigned by SPECTRUM.
Installing Multiple SpectroSERVERS Several SPECTRUM resource files specify the landscape handle. You must manually change each of these files to ensure that all SPECTRUM applications continue to function. A mismatch of landscape handles between resource files and what the SpectroSERVER is actually using can cause problems with Archive Manager, Data Export, and the Report Generator.
Designating a Master Catalog Designating a Master Catalog You can designate a dedicated SpectroSERVER to act as a master catalog, from which other VNMs (dedicated machines) can copy models. This master catalog is part of the dedicated SpectroSERVER’s database. In order to understand the relationship between the dedicated SpectroSERVER’s master catalog and the modeling catalogs on remote machines, the following should be considered.
Designating a Master Catalog Database Changes that Affect the Master Catalog Before you can copy the model type data to another distributed SpectroSERVER, you must designate your current VNM as the master catalog. Follow these instructions to set this machine as the master catalog. 1. As root, start SpectroGRAPH. 2. At the Universe level, select the VNM icon, and open the Topology view. 3. Open the SpectroSERVER Control view from: a. the Icon Subviews menu by selecting Control b.
Modeling the Landscapes This saves the master catalog model type data to the database of the remote server. You can change the catalog file name to another meaningful string. 4. Copy the catalog_file_name to each remote server machine. 5. In the SS directory of the remote server, run the following executable: SSdbload -catalog This loads the updated master catalog to another directory. If you want to copy the master catalog to other SpectroSERVERs, follow steps three and four.
Modeling the Landscapes NOTE It is recommended that you use a central workstation dedicated to modeling only landscapes and no other models in your Distributed SpectroSERVER setup. This will significantly reduce the workload placed on each SpectroSERVER but still allow access to all device models from this centralized, dedicated machine. To create each Landscape model: 1. Select Edit from the File menu 2. Select New Model from the Edit menu 3.
Modeling the Landscapes a. cd to the /SS-Tools directory b. Type lh_set A message similar to the following will display with this SpectroSERVER’s landscape handle: Aug 26 10:27:46 ERROR at CsDbLock.cc(320): Unable to lock lock file. SS Database landscape handle is 48 (0xc00000) VNM Name The name of the SpectroSERVER that this landscape model will represent. Generally, this is the same as the machine name on which the SpectroSERVER is installed.
Modeling the Landscapes Figure 2-2.
Example Distributed SpectroSERVER Configuration Example Distributed SpectroSERVER Configuration This section provides an example of a Distributed SpectroSERVER configuration using three SpectroSERVERs as an example. In this configuration: • SpectroSERVERs A, B, and C have each been installed with unique landscape handles (Figure 2-3). • SpectroSERVER A is the Main Location Server and the Dedicated Master Catalog. (Figure 2-3).
Example Distributed SpectroSERVER Configuration Figure 2-4.
Processd Processd Processd is a process launching and tracking daemon that provides SPECTRUM with the ability to control various processes that are run on various servers and clients in a distributed SPECTRUM environment. Processd starts processes when requested by an application such as the Control Panel. It can also start processes on system boot if configured by the user and can automatically restart critical processes in the event they die unexpectedly.
Processd 5. Type “makeinstdb -dir :/”. 6. Remove the CsProcdDb.k file by typing “rm CsProcdDb.k”. NOTE Even though the database is already corrupted, removing the CsProcdDb.k file alerts the processd daemon that there is a problem and allows it to proceed with reinitialization. Type “processd.sh start”. This will put processd back in a running state.
Chapter 3 Fault Tolerance This chapter describes how to set up fault tolerance procedures for SpectroSERVER. Overview of Fault Tolerance Fault Tolerance is provided by having more than one SpectroSERVER managing a landscape. At any time, only one copy of a landscape is active. That active landscape is called the primary landscape. The other inactive copies are called secondary landscapes. When a primary landscape fails, a secondary landscape becomes active and starts managing the network.
Overview of Fault Tolerance Precedence • data synchronization is the measure of how closely the secondary resource tracks changes to the primary resource. It can be measured by the time delay between the change to the primary and the corresponding change to the secondary. It can also be measured by how accurately the secondary server reflects the primary server, which may vary for different kinds of data. In SPECTRUM the data is synchronized by the SpectroSERVER and database mechanisms.
Overview of Fault Tolerance Establishing Fault Tolerance Establishing Fault Tolerance Fault tolerance is intended to provide continuous service for network failures only. The secondary landscape database should not be edited except as needed to fix the network failure. Any changes made to the secondary landscape are lost when the primary database overwrites the secondary database. To prepare your network for fault tolerance: 1. Designate one landscape as a primary landscape. 2.
Overview of Fault Tolerance Generic Configuration ! CAUTION When restarting the primary server, since connections are accepted before all of the models are activated (and it may take awhile for the models to activate) then your applications will switch back to the primary server and your secondary server will turn off polling before you can use the primary server to manage your network. To avoid such an event add this option to the command line when you restart the primary server: -wait_active.
Overview of Fault Tolerance Figure 3-1.
Overview of Fault Tolerance Fault Tolerance 3-6 Distributed SpectroSERVER
Appendix A Database Partitioning This appendix explains the concepts of, and procedures for, database partitioning SPECTRUM’s SpectroSERVER. This appendix describes partitioning procedures for the database portion of your SpectroSERVER. For more information on partitioning your network, refer to Chapter 2, Setting up a Distributed SpectroSERVER Environment.
Database Partitioning When to Partition When to Partition Partitioning preserves the work already invested in the database and should be considered if there is a significant amount of work invested in the current database (layouts, annotations, etc.). Otherwise, if the customization investment in the database is small, use AutoDiscovery to populate it.
Database Partitioning Database Partitioning Files Database Partitioning Files Several database partitioning files are created throughout the partitioning process. These files allow you to identify what is, what was, and what will be. Table A-2 lists the files and their function. Table A-2. File Database Partitioning Files Task Access Path AUDIT.TXT Each of the database partitioning tools produces an AUDIT.TXT file that contains debugging information about the tools operation.
Database Partitioning Partitioning the Database Partitioning the Database The following steps are required to partition a database. 1. Create directories for as many partitions as you are creating. If you want to split your database in half, you would make two directories where the first directory would contain the database that represents one half, and the second directory would contain the database that represents the other. 2. Copy the database files into each directory created. 3.
Database Partitioning Partitioning the Database a. Choose a hierarchy (Topology, Location, Org-Chart). For ease of viewing, navigate into a level that has 300 or fewer device models below it. NOTE To help decide where to start, you may run Inventory Reports from the Universe level. Inventory Reports is available from Generate off of Reports in the File menu. This will give you a listing of all of the models in the hierarchy. b.
Database Partitioning Partitioning the Database 10. Once the models are destroyed, shut down SpectroSERVER, disconnect from CLI and backup the pruned database using the command SSdbsave -cm . This backup copy of the partition safeguards your work while the conversion process is taking place. 11. Repeat steps 4 through 10 for each partition directory copy of the database. 12.
Database Partitioning Performing Diagnostics on Your Converted Database 14. Move the converted and saved database (i.e., the ) along with the .vnmrc and .watchrc files to the desired platform. Expand the database on the new platform with SSdbload -il and you are ready to run SPECTRUM. Repeat this step for each platform. Performing Diagnostics on Your Converted Database 1. Bring up SpectroSERVER in debug mode to validate the conversion process.
Database Partitioning Attributes To Be Converted The output files, LOOKER.BEFORE and LOOKER.AFTER, contain attribute values that look like the current landscape id. The looker program prints an attribute’s fields as: . The program also uses the following indicators to identify what looker found while examining the database. •Searching for... indicates the landscape id it was looking for.
