5 NETWORK ADMINISTRATION:

1.Network architecture
From Wikipedia, the free encyclopedia
In computing, network architecture is the design of a computer network.
In telecommunication, the term network architecture has the following meanings:
The design principles, physical configuration, functional organization, operational procedures, and data formats used as the bases for the design, construction, modification, and operation of a communications network.
The structure of an existing communications network, including the physical configuration, facilities, operational structure, operational procedures, and the data formats in use.
With the development of distributed computing, the term network architecture has also come to denote classifications and implementations of distributed computing architectures. For example the applications architecture of the telephone network PSTN has been termed the Advanced Intelligent Network. There are any number of specific classifications but all lie on a continuum between the dumb network (e.g. Internet) and the intelligent computer network (e.g. the telephone network PSTN). Other networks contain various elements of these two classical types to make them suitable for various types of applications. Recently the context aware network which is a synthesis of the two has gained much interest with its ability to combine the best elements of both.

2.Network engineering
In telecommunication, the term network engineering has the following meanings:
1. In telephony, the discipline concerned with (a) determining internetworking service requirements for switched networks, and (b) developing and implementing hardware and software to meet them.
2. In computer science, the discipline of hardware and software engineering to accomplish the design goals of a computer network.
3. In radio communications, the discipline concerned with developing network topologies.

3.Network management system
A Network Management System (NMS) is a combination of hardware and software used to monitor and administer a network.
Individual network elements (NEs) in a network are managed by an element management system.

4.Network monitoring
The term network monitoring describes the use of a system that constantly monitors a computer network for slow or failing systems and that notifies the network administrator in case of outages via email, pager or other alarms. It is a subset of the functions involved in network management.
While an intrusion detection system monitors a network for threats from the outside, a network monitoring system monitors the network for problems due to overloaded and/or crashed servers, network connections or other devices.
For example, to determine the status of a webserver, monitoring software may periodically send an HTTP request to fetch a page; for email servers, a test message might be sent through SMTP and retrieved by IMAP or POP3.
Commonly measured metrics are response time and availability (or uptime), although both consistency and reliability metrics are starting to gain popularity.
Status request failures, such as when a connection cannot be established, it times-out, or the document or message cannot be retrieved, usually produce an action from the monitoring system. These actions vary: an alarm may be sent out to the resident (SMS, email,...) sysadmin, automatic failover systems may be activated to remove the troubled server from duty until it can be repaired, etcetera.
Monitoring the performance of a network uplink is also known as network traffic measurement, and more software is listed there.
Contents
1 Various type of protocol
2 Servers around the globe
2.1 Software used in network monitoring
2.2 Network Management Systems
3 See also
4 References
5 External links
Various type of protocol
Website monitoring service can check HTTP pages, HTTPS, FTP, SMTP, POP3, IMAP, DNS, SSH, TELNET, SSL, TCP, ping and a range of other ports with great variety of check intervals from every 4 hours to every one minute. Typically, most website monitoring services test your server anywhere between once-per hour to once-per-minute.

Servers around the globe
Website monitoring services usually have a number of servers around the globe - USA, Europe, Asia, Australia and other locations. By having multiple servers in different geographic locations, monitoring service can determine if a Web server is available across different Networks worldwide. The more locations the better picture on your website availability.

5.Computer networking
Computer networking is the scientific and engineering discipline concerned with communication between computer systems. Such networks involve at least two devices capable of being netfucked with at least one usually being a computer. The devices can be separated by a few meters (e.g. via Bluetooth) or thousands of kilometers (e.g. via the Internet). Computer networking is sometimes considered a sub-discipline of telecommunications.
History
Carrying instructions between calculation machines and early computers was done by human users. In September 1940 George Stibitz used a teletype machine to send instructions for a problem set from his Model K at Dartmouth College in New Hampshire to his Complex Number Calculator in New York and received results back by the same means. Linking output systems like teletypes to computers was an interest at the Advanced Research Projects Agency (ARPA) when, in 1962, J.C.R. Licklider was hired and developed a working group he called the "Intergalactic Network", a precursor to the ARPANet. In 1964, researchers at Dartmouth developed the Dartmouth Time Sharing System for distributed users of large computer systems. The same year, at MIT, a research group supported by General Electric and Bell Labs used a computer (DEC's PDP-8) to route and manage telephone connections. Throughout 1960s Leonard Kleinrock, Paul Baran and Donald Davies had independently conceptualized and developed network systems consisting of datagrams or packets that could be used in a packet switching network between computer systems. In 1969 the University of California at Los Angeles, SRI (in Stanford), University of California at Santa Barbara, and the University of Utah were connected as the beginning of the ARPANet network using 50 kbit/s circuits.
Networks, and the technologies needed to connect and communicate through and between them, continue to drive computer hardware, software, and peripherals industries. This expansion is mirrored by growth in the numbers and types of users of networks from researcher


5 SYSTEM ADMINISTRATION:

System administrator
A system administrator, or sysadmin, is a person employed to maintain and operate a computer system or network for a company or other organization. System administrators are often members of an information technology department.
The duties of a system administrator are wide-ranging, and vary widely from one organization to another. Sysadmins are usually charged with installing, supporting, and maintaining servers or other computer systems, and planning for and responding to service outages and other problems. Other duties may include scripting or light programming, project management for systems-related projects, supervising or training computer operators, and being the equivalent of a handyman for computer problems beyond the knowledge of technical support staff.

1.WebSphere Application Server structure
Application Server 5.0 provides an entirely new packaging structure. Several installation images build on one another to incrementally expand the features available to you. Start with the base product installation, and then add features, for example, extended programming model enhancements or multi-node network deployment capabilities, as you need them. The two basic packages are Base Application Server and Network Deployment.
The Base Application Server package
A base WebSphere Application Server installation includes everything needed for a single Application Server process. Additional server processes can be logically grouped into nodes. A node can contain many servers, but cannot span multiple computer systems. A single computer system can have multiple nodes installed on it, each with multiple managed servers. For example, multiple nodes defined on a large multi-user enterprise server makes better use of the system resources, and can isolate projects from one another. Figure 1 depicts the base environment.

2.The Network Deployment package
A Network Deployment installation can support a network of computer systems that are configured to run collaborating instances of the base Application Server installation. The Network Deployment package provides centralized administration and workload management for a set of nodes, referred to as a cell. A cell has a master administrative repository that stores the configuration data for all of the nodes in the cell. Figure 2 depicts multiple systems in a Network Deployment cell, and shows that a base server can be added to a Network Deployment cell.
One computer is designated as the central deployment manager machine onto which the Network Deployment package is installed. The central deployment manager program that is included in this package manages all of the nodes in the cell. To add a Base Application Server installation to the cell, run the addNode program on the base installation. After this is completed, a separate node agent process is created that serves as an intermediary between the application servers on the node and the deployment manager. Administrative logic that runs in the node agent keeps the configuration data for a node synchronized with the master configuration data for the cell.
Besides grouping servers into nodes, another logical grouping of servers is the cluster. A cluster can contain servers on different nodes. All of the servers in a cluster must have the identical application deployment configuration, since the purpose of a cluster is to define servers that collaborate for workload balancing and failover capabilities.

3.Comparison of the administration implementation in Versions 4.0 and 5.0
Before getting into the details of Application Server 5.0, it is useful to compare the implementation of system administration in Version 5.0 with Version 4.0. Those familiar with Version 4.0 administration, especially with 4.0 Advanced Edition, will be pleasantly surprised by all of the new management features in Version 5.0.
There are significant differences between how you would handle administration in both Application Server Versions 4.0 and 5.0. One of the main differences is that the Version 4.0 Advanced Edition (AE) requires a database to hold configuration data while no edition of Version 5.0 requires a database. Version 4.0 AE administration is based on EJBs and all of the Version 4.0 administrative programs are EJB client programs. Version 5.0 does not use EJBs to store configuration data; therefore, none of the Version 4.0 administration programs, such as the Swing console, WSCP, and XMLConfig, are compatible with Version 5.0. Instead, Version 5.0 relies on XML configuration files and industry-standard JMX components to handle management functions.
The Version 4.0 administration program is a single AdminServer process that serves several functions simultaneously. In 4.0, the AdminServer runs on every node, and every instance of the AdminServer is equivalent to any other. In 5.0, the same functions that were combined in the 4.0 AdminServer have been separated into different specialized administrative programs. The node agent process discussed earlier runs on every node and is specialized to perform node-specific administration functions, such as server process monitoring, configuration synchronization, file transfer, and request routing. The single deployment manager process manages the entire cell, coordinating with the node agents for the various nodes in the cell.
Unlike Version 4.0, all administrative functions and programs are applicable to all editions of the product. The same scripting program, wsadmin, that works for the WebSphere Express edition also works for the full Enterprise package, even on the mainframe edition of Version 5.0. The same administrative console program, a J2EE Web application based on JSPs and the Jakarta struts framework, works for all editions of Application Server 5.0.

4.Application Server 5.0 administration architecture
In Version 5.0, the architecture for Application Server system management has been redesigned. Every process in Version 5.0 contains an embedded JMX agent, the JMX MBeanServer component. For each process, additional administrative services are built around this central management component.
Each managed component of the run time is exposed as a JMX MBean, which is registered with the MBeanServer. These managed resources are available externally by using JMX connectors to the MBeanServer. Each MBean has a unique identifier called the ObjectName, which is used in scripting and Java APIs. Application Server 5.0 supports two JMX connectors: the RMI/IIOP connector and the SOAP/HTTP(S) connector. Additional connector protocols are planned for future releases. Documentation for each MBean is installed with the product in the web/mbeanDocs directory under the root installation directory. The documentation describes the operations, attributes, and notifications that each MBean provides. Figure 3 shows architectural details of how all of the pieces fit together. When system security is enabled, all administrative connectors are secure. You must map all administrator userIDs to one of the administrative roles defined below. When an administrative client program, such as the console, scripting, command line, or custom program, attempts to perform an administrative function, the userID of the calling code is obtained and compared to the privileges granted to the role for that particular user. If the user does not have appropriate privileges, then the request will be rejected.
The following four roles separate the administrative functions into layers of privilege:
Monitor. This role can view configuration and run-time settings, but cannot modify anything.
Operator. This role can perform run-time operations, but cannot modify the persistent configuration. For example, an operator can start or stop a server but not change the configuration for that server.
Configurator. This role can modify the persistent configuration for the system, but cannot perform run-time operations on live objects. For example, a configurator can install applications into the system, but cannot start or stop a server.
Full Administrator. This role can perform all administrative functions.
In the base Application Server package, the administrative client programs attach directly to the server process and send administrative requests to that single process. In a Network Deployment environment, the administrative client programs can attach to any point in the topology (deployment manager, node agent, or managed process). Generally, administrative clients attach to the deployment manager because all servers can be controlled from that process. When a request for an MBean operation is submitted to the deployment manager, it is automatically routed to the server on which the target run-time component is executing.
In addition to operational requests (for example, stopping a server) and configuration requests (for example, changing an attribute), administrative programs in Version 5.0 can register as listeners for distributed event notification from any of the MBeans running in the network. Several MBeans generate an event notification when something significant occurs in their logic (for example, the Server MBean generates notifications when it starts and stops). Administrative clients can register to receive callbacks when these notifications are broadcast.
As described previously, configuration data is stored as a set of files that make up the master configuration repository. In a Base Application Server environment, all documents are stored on the same system as the server. In a Network Deployment environment, the deployment manager maintains the full set of configuration documents for the entire cell, and each node in the cell only gets a subset of the documents that apply specifically to that node. Since each node has the subset of configuration information required for processes defined on that node, you can start and control the servers even if the central deployment manager process is temporarily unavailable. Figure 4 depicts how administrative commands are routed between the processes in the cell, and how different servers read the various parts of the configuration data.
Administrative command routing and configuration flow 5.Application Server 5.0 administration tool sets
System administration provides a variety of tools for managing WebSphere Application Server. These tools can be categorized into four general tool sets that are available with most editions of the product:
Administrative Console
Scripting tool
Command line tools
Java programming API
Administrative Console
The administrative console is a graphical interface that provides many features to guide you through deployment and systems administration tasks. It is extremely useful for helping you get started exploring the available management options. Various wizards guide you through the more complicated processes. The administration console program is documented in the Application Server 5.0 InfoCenter. Figure 5 shows the WebSphere Administrative Console home page.


Scripting tool
The Application Server administrative scripting program, wsadmin, is a powerful, non-graphical command interpreter environment that lets you execute administrative operations interactively or in a script file. The wsadmin tool is intended for production environments and unattended operations. The wsadmin tool is documented in the Application Server 5.0 InfoCenter. It is built on top of the Bean Scripting Framework that is shipped with Version 5.0. This lets the program support several languages for scripting Application Server administrative functions. The initial release only supports the Tcl syntax, but additional scripting language support is already underway for future product updates.
The wsadmin scripting tool has three modes of operation:
Interactive mode. This lets the user enter commands and view the response on a command line prompt. This mode is useful for learning the scripting tool and its capabilities. It is also useful for prototyping command syntax to verify the options before building a larger script.
Batch mode. This lets the user supply a set of script commands in a file that the tool executes as a program.
Command mode. This lets the user enter a single command from the regular operating system command window and executes this one command, returning control to the operating system command shell.
The wsadmin tool is most often executed as a client attached to a running server. You can also run it in a "local" execution mode where a running server is not required. In this mode, however, the function is limited to only configuration changes since a server run time is not available to receive operational requests.
Four Application Server administration scripting objects reflect the underlying product architecture:
AdminControl. Exposes the operational aspects of the system so that you can invoke JMX operations on the live run-time components through the MBean interface.
AdminConfig. Exposes the configuration for the system so that you can update the XML configuration files.
AdminApp. Exposes the application deployment options for the system; this is essentially a specialized configuration object for installing and deploying applications.
Help. Provides dynamic information about the operations, attributes, and notifications available on any JMX MBean in the system.
The wsadmin tool is primarily intended for rapidly assembling small control programs using the available Application Server administrative functions. You can develop more sophisticated administration programs using the Java API for Application Server administration (described below). However, the combination of full scripting language constructs, such as loops and variable evaluation, along with Application Server administration functions provides powerful capabilities.

Command line tools
Command line tools are simple programs that you run from a command prompt to perform specific tasks. Using the command line tools, you can start and stop application servers, check server status, add or remove nodes, and complete similar tasks. The command line tools provided with Application Server 5.0 are restricted for use on a single local node.
All of the command line tools are Java programs that use the same Application Server 5.0 administration APIs as the console and the wsadmin tool, which are discussed in the next section. The following is a partial list of some of the command line tools available with Application Server 5.0. A complete list of the command line tools is available in the Application Server 5.0 InfoCenter.

Java programming API
Application Server 5.0 supports a Java programming interface for developing administrative programs. All of the administrative tools supplied with the product are written according to the API, which is based on the industry standard JMX specification.
Using the administrative programming API, you can:
Write your own custom administration client to perform specific administration functions. The command line tools available with Application Server 5.0, including the wsadmin tool and the console, are client programs that use the public administration APIs to carry out their tasks. Custom administration client programs can be simple or extremely complex. For example, you could write a client that only lets you start and stop clusters. Or, you could write a specialized administration client program to monitor certain metrics in the server and adjust configuration settings if the metrics exceeded some threshold.
Extend the basic Application Server administration system with your own custom MBeans that expose the management interface specifically aligned for your requirements. For example, your application might have its own run-time properties that you can adjust to tune the application while it is executing. Your application can implement a JMX MBean that exposes these attributes and other useful operational requests. Using the Version 5.0 administration programming interfaces, you can add your MBean to the set provided with Application Server, and control your application, along with the rest of the system, using the wsadmin scripting client. You can even write a custom server extension and expose its functionality to the Application Server administration system as a JMX MBean.
The Application Server administration programming API is fully documented in the javadoc, which is provided with every installation (it is located in the web/apidocs directory under Application Server's root installation directory). The Application Server administration API is based on standard JMX interfaces and classes, and the JMX javadoc is also provided with each installation. The com.ibm.websphere.management package contains the public Application Server management interface.
Many helper classes and interface definitions are associated with the Version 5.0 administrative programming APIs. If you plan to create custom administration code, you should familiarize yourself with the public javadoc for the product. Future articles in this series will explore the details of how to use these administration programming APIs, and will provide detailed examples of custom administration programs and system extensions.

first

At last naa nko!!!!