تحميل الهوت ميل ماسنجر الجديد مجانا 2010 hotmail download

The USB standard that all of us are currently using to power our mice, MP3 players, scanners, printers and assorted other peripherals is technically USB1.1. When it was originally introduced it was a heck of a lot faster than anything else around. Now USB1.1 is dated and ready to be usurped by a newer, faster standard you may have heard rumblings about. That new standard is called USB 2.0.

USB 2.0 operates at 480Mbps, about 40X times faster than USB 1.1 which currently works at a snails pace of just 12Mbps. For arguments sake, IEEE 1394 Firewire has transfer speeds of 400Mbps and has been around for a year or two now. Having had a taste of Firewire which has seen itself largely segmented to the digital video marketplace, USB2.0 is an exciting development. While there have been many devices launched under FireWire that enabled computers to have hard drives, CD-burners and similar devices located externally, the mainstream PC market never really seemed to embrace it – possibly due to the fact that it has become a standard on Mac computers.

While I have yet to see any mainstream manufacturer, or any for that matter drop IEEE 1394 FireWire onto a motherboard, MSI have already done the very same with USB 2.0 – a very good sign that it will see wide implementation amongst PC makers.

Wide implementation opens up the doors for more external devices like hard drives, CD-burners, DVD drives and other data-have devices. While this was technically possible with USB1.1, the data transfer times were so slow that it became impractical vs. IDE. With speeds of 480Mbps, USB2.0 takes care of these issues in almost the same manner that FireWire has. The main benefit is of course the backwards compatibility (both in terms of devices and interfaces) and lower cost of implementation USB2.0 brings to the table. USB2.0 uses the exact same cables and ports.

At the moment, USB2.0 drivers are not native to Windows XP. This may change with subsequent updates, and as more devices make the upgrade to the new standard. Intel have recently announced the D850MV-SE, a USB2.0 enabled Pentium 4 (RDRAM), and MSI have the 845Pro2-RU with USB2.0 support via NEC chipset. The groundwork is also there for USB2.0 networking, which would offer fast connectivity between PCs like MSIs PC-to-PC technology currently does on the USB1.1 standard.

Companies currently offering USB2.0 peripherals include: ACOM, Adaptec, Addonics, ADS Technologies, Archos, Argosy Research, ATEN Technology, Belkin, BusLink, DataFab Systems, DoTop Technology, Dura Micro, Fellowes Manufacturing, Fujitsu, Good Way Technology, I-O Data Device, Iogear, LaCie, Maxtor, Melco, Microtek International, Opteon Corp, Orange Micro, Pacific Digital, Plextor, QPS, Quik Tech Solutions, Ratox Systems, RocketPod, Seiko Epson, Siig, Sony, System Talks, and Yamaha who have a 20X CD-RW Recorder.

HDMI (High-Definition Multimedia Interface) is a connection standard that was first developed by Hitachi, Panasonic, RCA, Silicon Image, Sony, and Toshiba in 2002.

With analog technologies moving to digital, youre probably cringing at the prospect of your entire VHS collection crumbling over time. Buying and installing a capture card— as well as figuring out how to use your PC to convert these tapes to digital format, is way complicated—but theres a superb alternative. The Sony DVDirect VRD-MC5  is the easiest way to convert your entire VHS collection (as well as video from your camcorder and photos from your digital camera) into DVD format, with one click of a button. All of this is done without the use of a PC, and you can see whats being recorded on its 2.5-inch LCD screen. Its worthy of an Editors Choice, just like its predecessor, the VRD-MC1, though this new model is unique in the market.

The Seagate FreeAgent Go is a new breed of portable hard drive: one with a prodigious capacity—500GB is larger than many internal desktop drives—as well as a convenient ability to dock the drive to a PC like you might with an iPod. The Go has a wealth of features that make it easier to back up your data than other drives do, which is one reason why Im giving it the Editors Choice for portable hard drives.

Too many people dont back up their important files (pictures of the grandparents with the kids, that rare CD they ripped and then lost, 15 years worth of résumé updates). All of this data is irreplaceable but is also a hassle to back up using traditional CDs or DVDs. A 500GB drive has enough space to keep multiple copies of each file. Thanks to the optional dock, which is a must-have, and the software, backing it all up is a breeze

The lifespan of a Dell Inspiron laptop is usually quite substantial, sometimes to the point where it becomes long in the tooth. Thus its unusual to be mourning the loss of the Dell Inspiron 1520 after only six months on the market. Stepping into the spotlight to replace it is the revamped Dell Inspiron 1525. While theres no miracle weight loss here, the 6-pound frame is nearly half a pound lighter than the 1520s, and the tapering design gives it a slimmer silhouette (similar to that of the Dell XPS M1530). An unpleasant side effect of going small, however, is that powerful graphics cards will not be offered as an option—only integrated graphics.

The Sony Cyber-shot DSC-T77 ($299.99 direct) is a beauty. Its compact design, metallic features, and touch screen make it feel like a luxury item. Aside from color fringing in the corners of images, most users will find the shots they take dazzling. The cameras 3-inch LCD touch screen is very responsive, and the user interface is more intuitive than those of competing touch-screen models, such as the Nikon Coolpix S60 or the Kodak EasyShare v1073. The less-expensive Canon PowerShot SD790 IS ($249) and Nikon Coolpix S610c deliver images that are on a par with T77s, but they dont have touch screens and fun in-camera retouching options. Beyond that, this Cyber-shot is just handsome. Of course, as with any camera that employs a touch screen, battery life suffers.

PCI (Peripheral Component Interconnect) and AGP (Accelerated Graphics Port) are two different technologies used to connect expansion cards – such as video, sound, and graphics cards – to your PC. The main difference between the two is speed, particularly when it comes to processing graphics. Gone are the days of simple words and numbers – these days we expect our business, entertainment and educational software to impress us with fancy images, charts, icons, textures, and 3-D graphics. Software developers, aware of our expectations for graphics intensive applications, are continually pushing the technology envelope by incorporating larger and more complex images into their programs. As programs become more graphics intensive, they require more bandwidth and memory to display each screen and image. If bandwidth and memory resources are limited, a bottleneck occurs, causing the software, and generally the PC, to slow to a crawl while the graphics are processed. In the past, several attempts have been made to reduce the bottlenecks associated with graphics processing. A significant breakthrough occurred in 1993 when Intel introduced the PCI bus. The PCI standard uses a technique called bus mastering, which allows the CPU and expansion cards to process information simultaneously. The bus operates at a bandwidth of 66MHz, and PCI cards can communicate with the PC using 32- or 64-bit data. PCI provides fast communication between the CPU and peripherals, but peripheral devices have to compete with each other for bandwidth. The PCI bus is currently the highest performing general I/O bus used in PCs, and it provides adequate acceleration and processing features for most games, video and multimedia applications. PCI is able to handle 2D images and general business graphics quite competently, but it can be challenged by intense 3D graphics. Thats where AGP comes in. To create 3D images, the graphics controller must be able to manage texture data and z-buffer information. Texture data produces the digital representation of the surface of an object and generates properties such as transparency, which makes the object look more realistic; z-buffer information provides depth, which also increases realism. Both of these data sets are memory intensive, and unfortunately, both compete for the same memory space. Intel introduced AGP in 1996 in an attempt to solve this dilemma. The AGP specification is based on the PCI 2.1 specification, but unlike PCI, AGP is designed solely for use with graphics cards. Its not intended to replace the PCI interface as the general I/O interface bus; its primary purpose is to deliver high-performance graphics, including 3D imaging. AGP has the ability to quadruple the theoretical bandwidth of current PCI buses, and has the potential to perform even higher. This increased performance is achieved by introducing a dedicated point-to-point channel that gives the graphics controller direct access to main system memory. In addition, the AGP channel is 32 bits wide and runs at 66MHz, which translates into a total bandwidth of 266MBps. AGP also supports two fast modes, 2x and 4x, which have throughputs of 533MBps and 1.07GBps respectively. Features such as texturing and pipelining further enhance the graphics processing ability of AGP. Texturing, also called Direct Memory Execute mode, allows texture data to be stored in main memory. Pipelining is a process that enables the graphics card to send several instructions together instead of sending one at a time. AGP improves the overall performance of a PC in several ways: 1. Graphics operations are faster because they dont have to share bus bandwidth with other peripherals. 2. Peripheral devices are also faster because they dont have to share the PCI bus with the bandwidth intensive graphics operations. AGP operates concurrently with, and independent from, most transactions on the PCI bus. Since the AGP bus is handling all graphics tasks, the PCI bus is free to serve devices such as disk controllers, modems and network cards. 3. The quality of the 3D graphics created using AGP is very high, and since they are extremely realistic, the quality of both 2-D and 3-D software is improved.

Unfortunately, like most computer parts, computer hard drives have been appointed names and descriptions that are nearly always based on hi-tech gobble-de-gook terms. When looking at purchasing a new hard drive this will be your first issue to handle. And, the first term youll need to come to grips with is, “Do you want an IDE, ATA, or SATA hard drive??  Yes, sometimes shopping for computer parts can be a real head banging exercise.
                            
Recent years have seen many changes in hard drive technology. Like most things related to computers nearly of these changes have related to speed and size. To be more precise, faster (as to how quickly a hard drive can access and move information backwards and forwards) rather than slower and, larger (in the amount of data it can hold) rather than smaller. So, because performance is such an important selling point a large part of a hard drives description relates to either its particular size or speed.

ATA, SATA and SATA II
The terms ‘ATA’ (Advanced Technology Attachment), ‘SATA’ (Serial ATA) and ‘SATA ll  (Serial ATA 2) refer to both a measurement standard and an electronic method of transferring information (data) backwards and forwards between the hard drive and the rest of the computer. Kind of like the water pipe system between your house and the city water department – except in this case the water goes both ways. ATA in our water example would represent a method by which your cities water department can take water out of a reservoir and get it to your kitchen tap measured in minutes and gallons. The ATA computer standard is just one recognised method by which your hard drive can do a similar job, only with data, and in milliseconds and megabytes.

ATA hard drives (also generally known as IDE or Integrated Drive Electronics – the terms actually mean the same thing) have been the most common standard for hard drives manufactured since 1986. However, the ATA standard has been consistently developing over these years and there have been several changes to better the size and speed of the hard drives which it can support.

ATA Development Phases
All in all, the ATA standard has moved through seven recognised phases, (ATA-1, 2, 3, etc) and in 2001 stage 7 ATA hard drives came on the market (commonly called Ultra ATA-133). These could make data transfer rates of up to133 MB/sec (megabytes per second). ATA-7 is thought to be the last stage of development before Serial ATA took over. At this stage to make clear the distinction between ATA and the newer SATA standard, the older ATA standard was redefined and named Parallel ATA (or PATA). In other words ATA, PATA and IDE are all different names for the same thing. And, as youll probably hear of these at some time you may as well know that IDE, FASATA and ULTRA ATA are all different company names for their particular branding of the current ATA technology at the time.

Confused? Like I said at the beginning there is so much jargon in the computer world. It really doesnt help when there are several different hi-tech names that all refer to the same thing. It just goes to show how much competition (and money) there is amongst computer related companies to have their particular brand of the current technology accepted as the world standard. However, they all dipped out as plain old ATA became the accepted term.

SATA Arrives
Anyway, in the year 2000, hard drive technology came up with a new hard drive standard called Serial ATA, more commonly known as ‘SATA’. The SATA hard drives proved superior in several important areas and within a short period of time SATA had become the new standard.

For the more technical here are the differences between ATA (or PATA) and SATA. Advanced Technology Attachment (ATA) is based on a 16 bit parallel interface and is normally used to control computer hard drives. However, Serial Advanced Technology Attachment (SATA) is a single bit serial advancement of the Parallel ATA. The cable connecting an ATA hard drive uses a ribbon cable with 40 wires (looks a bit like a licorice strap) as opposed to a SATA cable which only has 7 wires. Because of this it is easy to tell a SATA hard drive from an ATA hard drive by the much smaller power and data connections used on the back of the two different hard drives.

When comparing PATA against SATA, SATA hard disk drives have several performance benefits which distinguish them from ATA hard drives. Notably SATA hard drives operate cooler and on higher bandwidths which equates to faster data transfer. The latest models of PATA hard drives (ATA-7) offer data transfer rates of 133 MB/second. The first SATA standard provided an immediate data transfer boost of up to 150 MB/second, and as of 2004 the new SATA II standard allows for transfer rates of 300 MB/second.

Lets sum all this up:

• 
  
  PATA and ATA mean the same. They both stand for “Parallel Advanced Technology Attachment. The P was added to make the difference clearer when SATA came along. ATA is still the more common term.
  

• 
  
  Late model ATA hard drives are still fulfilling most requirements. SATA hard drives are the next step up, ie – slightly better performance. And SATA II hard drives are the highest performing models. However, generally speaking unless you are running large, high demand programs you most likely will not notice any advantage.
  
  
  
• 
  
  When you hear ATA vs SATA you now know that the difference between the latest ATA hard drives and the newer SATA hard drives is a performance boost of about 5%. (Considerably more for SATA II hard drives but youll also need several other changes within your computer to take advantage of them).
  
  
  
• 
  
  When it comes to SATA vs IDE hard drives (or ide vs sata), we are in fact actually talking about SATA vs ATA as IDE is simply a company brand name that has stuck that means the same as ATA
  
  
  
• 
  
  ATA 100 and 133 hard drives (also known as ULTRA  – the latest of the ATA hard drives) are still more common in new computers than SATA because of their lower price.
  

• 
  
  Technology advancement never stops. If you are worried that if you purchase a new hard drive now youll miss out on something better tomorrow then you will never get one. The new hard drives on the market today were most likely developed 2 to 3 years ago – thats just the way it is.

When it comes to making your new hard drive purchase then in most cases an ATA 100 or 133 harddrive will be quite adequate. However, in a couple of years its likely that ATA technology will disappear and SATA will become the accepted standard. In my opinion purchasing a 7200 rpm SATA hard drive is the current entry level for a new hard drive, not necessarily for the performance but primarily for the compatibility with future systems and components. And, If you are a gammer or a video editor then the additional benefits of faster performance should see the extra money for a SATA II drive well spent.

Using hardware control software

CSM hardware control software provides remote hardware control functions for cluster nodes and devices from a single point of control. CSM allows you to control cluster nodes remotely through access to the cluster management server. From the management server, an administrator runs cluster management commands using the command line, Web-based System Manager graphical user interface (GUI), System Management Interface Tool (SMIT) panels, or the DCEM graphical user interface.

CSM supports hardware control for non-node devices, and provides power control and where applicable, remote console access for a wide range of devices such as hardware control points, external console servers, and remote supervisor adapters. The predefined dynamic device group AllDevices includes all defined devices.

CSM hardware control functions depend on the specific hardware, software, network, and configuration requirements described in this book. The requirements for remote power are separate and distinct from the requirements for remote console. clusters without the hardware, software, network, or configuration required to use CSM hardware control can still have CSM installed on some or all cluster nodes. However, in such clusters the hardware control commands may be inoperable or provide only limited function.

CSM for AIX 5L supports remote hardware control for pSeries, xSeries, BladeCenter, SP Nodes, p660 nodes, 325 and 326, and OpenPower 720 from an AIX management server. Hardware control commands can be run on the AIX management server to simultaneously control both AIX and Linux nodes in a mixed cluster. See the CSM for AIX 5L and Linux: Administration Guide for a complete description of CSM mixed clusters.

In CSM documentation “p660 nodes” refers to pSeries 660 nodes (which are not HMC-attached), and the M80, H80, 6H0/6H1, and 6M1 RS/6000 servers.

CSM for Linux supports remote hardware control for xSeries, pSeries, BladeCenter, and eServer 325 and 326 servers from a Linux management server.

The following list describes the CSM hardware control commands; see the man pages or the CSM for AIX 5L and Linux: Command and Technical Reference for detailed command usage information.

chbmcconsusr

Defines a remote console user name for node BMCs.

chhwdev

Changes a device definition in the CSM database.

chrconsolecfg

Removes, adds, or rewrites console entries in the Conserver configuration file.

chsnmp

Sets the SNMP agent configuration information for xSeries and BladeCenter servers.

cspadm

Administers the cspd daemons log file and debug flags.

cspcfgframe

Configures SP frame hardware control points for expansion I/O units.

cspcfgio

Displays the configuration information for expansion I/O units, IBM POWER3 SMP High Nodes (F/C 2054), and IBM 375 MHz POWER3 SMP High Nodes (F/C 2058).

cspcmds

Controls the state of SP Nodes, SP frames, and p660 nodes in the cluster.

cspmon

Monitors the state of SP Nodes, SP frames, p660 nodes, and expansion I/O units in the cluster.

definehwdev

Defines the devices in a CSM cluster.

getadapters

Collects information for LAN adapters.

hwdevgrp

Manages device group definitions in the CSM database.

lsbmcconsusr

Returns the remote console user names for node BMCs.

lshwdev

Lists the device definitions in the CSM database.

lshwinfo

Collects node information from one or more hardware control points.

lshwstat

Collects environmental and Vital Product Data (VPD) information from xSeries and BladeCenter servers. This command is not supported for CSM for Linux on pSeries.

lssnmp

Collects SNMP agent configuration information from xSeries and BladeCenter servers.

netboot

Initiates a network boot and install of an AIX node over the CSM cluster network.

rconsole

Opens a remote console for a node.

rconsolerefresh

Refreshes the Conserver daemon.

reventlog

Collects service processor log information for xSeries and BladeCenter servers.

rmhwdev

Removes device definitions from the CSM database.

rpower

Boots, resets, powers on and off, and queries nodes, devices and CECs.

systemid

Stores the user ID and password required for internal programs to access remote hardware.

Hardware control attributes

You must define the hardware-related attributes for nodes or non-node devices. In some cases default values are provided. If these defaults are acceptable, you do not need to provide the attribute values when you define the node. Hardware control attributes depend on the kind of hardware you plan to use.

For a list of the hardware control attributes that you define for a node, see Hardware control attributes.

For a list of the hardware control attributes that you define for a device, see Defining non-node devices for the cluster.

Hardware and network requirements

CSM for AIX 5L or Linux hardware control depends on the specific hardware and network requirements described in this book. The management server can be connected to cluster nodes and external networks using various configurations of IBM and non-IBM hardware and software that meet the CSM architecture requirements described in this book. For the specific cluster hardware models required to use CSM 1.4, see Planning for CSM for AIX nodes. See Hardware configuration for model-specific hardware control configuration requirements.

Virtual LANs (VLANs)

A VLAN (virtual Local Area Network) is a division of a local area network by software rather than by physical arrangement of cables. Dividing a LAN into subgroups can simplify and speed up communications within a workgroup. Switching a user from one VLAN to another using software is also more efficient than rewiring the hardware.

IBM suggests creating one or more VLANs for the CSM management server, managed devices, and hardware control points, and one or more separate VLAN for the CSM management server and cluster nodes. Although cluster hardware control points and nodes can be on the same VLAN, limiting access to the management VLAN reduces security exposure for IP traffic on the management VLAN and access to hardware control points.

The VLANs refer to VLANs as defined by IEEE standards – see http://standards.ieee.org/ for details. Figure 1 Figure 3 shows a network partitioned into three virtual LANs; management, cluster, and public VLANs, which are defined as follows:

management VLAN

Hardware control commands such as rpower and rconsole are run on the management server and communicate to nodes through the management VLAN. The management VLAN connects the management server to the cluster hardware through an Ethernet connection. For optimal security, the management VLAN must be restricted to hardware control points, remote console servers, the management server, and root users. Routing between the management VLAN and cluster or public VLANs could compromise security on the management VLAN. The management VLAN is also referred to as the service VLAN in CSM documentation.

Note:

The management VLAN is subject to the RSA restriction of 10/100 Mb/s.

cluster VLAN

The cluster VLAN connects nodes to each other and to the management server through an Ethernet connection. Installation and CSM administration tasks such as running dsh are done on the cluster VLAN. Host names and attribute values for nodes on the cluster VLAN are stored in the CSM database.

public VLAN

The public VLAN connects the cluster nodes and management server to the site network. Applications are accessed and run on cluster nodes over the public VLAN. The public VLAN can be connected to nodes through a second Ethernet adapter in each node, or by routing to each node through the Ethernet switch.

Hardware control overview and sample configurations

CSM communicates with hardware control points to request node power status, reboot, and power on and off functions. A hardware control point is the specific piece of hardware through which the management server controls node hardware. Hardware control points should be on the management virtual LAN (VLAN) and connected to the hardware that ultimately controls the power functions.

The supported hardware control points are:

• HMC for HMC-managed pSeries nodes
  
• Frame supervisor for SP Nodes
  
• CSP serial port for p660 nodes
  
• RSA for xSeries
  
• Management module for BladeCenter
  
• BMC for the eServer 325, 326, xSeries 336, and xSeries 346
  
• APC MasterSwitch for non-node and other devices that do not have another hardware control point such as an RSA and require the APC MasterSwitch.

For SP Nodes and p660 nodes, the connection is from a dedicated tty port on the management server to the frame supervisor or CSP serial port through a serial RS-232 line.

For details on defining tty ports for SP Nodes and p660 nodes, see the “Prepare the control workstation” section in Chapter 2 of the PSSP: Installation and Migration Guide, located at http://www.ibm.com/servers/eserver/pseries/library/sp_books/pssp.html.

Remote power software and configuration describes the remote power configurations for your cluster when you are using hardware control.

CSM communicates with console server hardware to open a console window for a node on the CSM management server. Console servers must be on the management VLAN, which connects the management server to the cluster hardware, and connected to node serial ports. (See Virtual LANs (VLANs).) This out of band network configuration allows a remote console to be opened from the management server even if the cluster VLAN is inaccessible. For example, if the cluster VLAN is offline, remote console can still access the target node to open a console window.

For HMC-attached pSeries, the HMC is the remote console server. For SP Nodes and p660 nodes, an independent device does not exist that can serve as a remote console server; console traffic is managed by the frame supervisor or p660 server firmware. xSeries servers can use any of the following console servers:

• MRV IR-8020, IR-8040, LX-4008S, LX-4016S, and LX-4032S
  
• Avocent CPS1600
  
• Cyclades AlterPath ACS48

Linux on pSeries clusters use the HMC for remote console; no additional console device is required or supported.

BladeCenter HS20-8678 blade servers that are part of an IBM 1350 Cluster require the 1350 Serial Port Module (SPM) option in order to support remote console. The SPM must be connected to an MRV IR-8020 or IR-8040 console server. HS20-8678 blade servers that are not part of a 1350 Cluster, or that do not have the SPM option, cannot support remote console. Consoles for these servers may be viewed, one at a time, by accessing the Management Modules web interface and selecting “Remote Control” from the “Blade Tasks” list.

BladeCenter HS20 (other than HS20-8678), HS40, and JS20 blade servers support remote console through the Ethernet Switch Module, using Serial Over LAN (SOL). Refer to your BladeCenter documentation for information on enabling and configuring SOL. To ensure maximum reliabilty, verify that the most up-to-date firmware is installed for the following components:

• BladeCenter HS20-8677 chassis: Management Module and Ethernet Switch Module
  
• HS20 (other than HS20-8678), HS40, and JS20 blade servers: Flash BIOS and Integrated Systems Management Processor (ISMP)

You can view the installed versions of these components in the Management Modules Web Interface by selecting “Firmware VPD” from the “Monitors” navigation panel. For information on the latest available versions, see the IBM Servers – Software and device drivers web page:

http://www.ibm.com/pc/support/site.wss/MIGR-4JTS2T.html

See your BladeCenter documentation for information on updating firmware levels.


xSeries 336 and 346 servers also support remote console via SOL. For these servers, remote consoles are opened through the on-board Baseboard Management Controller (BMC). See Remote console configuration. To ensure maximum reliability, ensure that the most up-to-date firmware is installed for the following components: 



Flash BIOS

Baseboard Management Controller


For information on the latest available versions, see the IBM Servers software and device drivers web page: http://www.ibm.com/pc/support/site.wss/MIGR-4JTS2T.html.


Remote console software describes the remote console software for your cluster when you are using hardware control while Remote console configuration describes the different kinds of remote console configurations.


Linux on pSeries clusters use the HMC for remote console; no additional console device is required or supported.

Attention!

The diagrams discussed in this book are provided for conceptual explanation only. They are not intended to be literal depictions of how to configure a specific cluster. See the  Cluster 1350 for Linux or 1600 for AIX documentation resources listed in Related information for specific cluster hardware configuration details. For specific RSA and ISMP connectivity requirements, see the hardware documentation resources listed in Related information.


For a list of the hardware control attributes used in the diagrams, see Hardware control attributesHardware control attributes.


The examples and diagrams in this chapter are as follows:



Conceptual diagram: xSeries, BladeCenter, and eServer 325

Linux node attributes example

Conceptual diagram: Linux on pSeries


Conceptual diagram: HMC-managed pSeries, SP, and p660 nodes


Figure 1 shows the hardware and networking configuration required for using CSM hardware control with IBM HMC-managed pSeries, SP, and p660 nodes. The HMC-attached pSeries server in the diagram is a single piece of hardware that has been partitioned by HMCs into 16 LPARs (nodes). The management server connects to the management and cluster VLANs through Ethernet adapters. Nodes on HMC-attached pSeries servers must be connected to the cluster VLAN and directly or indirectly to an HMC. Configuration for a public VLAN is flexible and can be defined by the system administrator. See Node hardware attributes for example node attribute definitions corresponding to Figure 1.


Each SP frame connects to the CSM management server through an RS-232 line cabled from the frame supervisor to a tty port on the management server. The frame supervisor requires a daisy-chain connection to the node supervisor for each server in the frame. Each p660 server connects to the CSM management server through its own RS-232 line cabled from its CSP serial port to a tty port on the management server. For multiple SP Nodes and p660 nodes, additional tty extender adapters must be connected to the management server.

Note:


For details on defining tty ports for SP Nodes and p660 nodes, see the “Prepare the control workstation” section in Chapter 2 of the PSSP: Installation and Migration Guide, located at http://www.ibm.com/servers/eserver/pseries/library/sp_books/pssp.html.
href=”/infocenter/clresctr/topic/com.ibm.cluster.pssp.doc/psspbooks.html”

CSM hardware control configuration for IBM HMC-attached pSeries, SP Nodes, and p660 nodes


Figure 1. CSM hardware control configuration for IBM HMC-attached pSeries, SP Nodes, and p660 nodes



AIX node attributes example


Figure 2 shows the relationship between CSM node attributes and the internal hardware names used in Figure 1. For remote power and remote console to work as expected for HMC-attached pSeries servers, this matching of node attribute names in the CSM database to the internal hardware values must be correct for all HMCs in the CSM cluster. Likewise, the tty port number on the management server and frame slot number must match the hardware control attribute values for all SP Nodes and p660 nodes in the CSM database.

CSM hardware control attribute values for AIX nodes


Figure 2. CSM hardware control attribute values for AIX nodes



Conceptual diagram: xSeries, BladeCenter, and eServer 325


Attention!

The diagrams discussed in this book are provided for conceptual explanation only. They are not intended to be literal depictions of how to configure a specific cluster. See the  Cluster 1350 resources listed in Related information for specific cluster hardware configuration details. For specific RSA and ISMP connectivity requirements, see the hardware documentation resources listed in Related information.

For a list of the hardware control attributes used in the diagrams, see Hardware control attributesHardware control attributes.


Figure 3 shows the hardware and networking configuration required for using CSM hardware control with xSeries, eServer 325, and BladeCenter servers running Linux.


The management server shown in the diagram connects to the management and cluster VLANs through Ethernet adapters. The console servers (mrv01, mrv02) connect to the management VLAN through Ethernet adapters, to the xSeries and eServer 325 servers, and to BladeCenter servers through the Cluster 1350 Serial Port Module option. BladeCenter HS20-8832 and JS20-8842 blade servers do not require an attached console server. They provide remote console independently using the Serial Over LAN feature.

The IBM Cluster 1350 Serial Port Module is an optional part that must be ordered separately to connect BladeCenter HS20-8678 blade servers to an MRV console server. This connection provides rconsole command function for HS20 BladeCenter servers. See the topic “Launching a remote console” in CSM for AIX 5L and Linux: Administration Guide for the part numbers and configuration required for this alternative to using a Web browser for HS20 BladeCenter remote console function.


JS20 BladeCenter servers support remote console function independently; they do not require an attached console server. JS20 servers use a serial over lan connection for remote console, which requires a connection to the eth1 Ethernet adapter. Thus, BladeCenter JS20 servers must connect to the management modules eth1 port. BladeCenter HS20 servers must connect to the management modules eth0 port


The management VLAN connects to the IBM Remote Supervisor Adapter (RSA) in select xSeries servers. The servers must be connected to the cluster VLAN through their first Ethernet adapters (eth0), and directly or indirectly to an RSA. An RSA connects to its node Internal Systems Management Processor (ISMP) port, and up to 24 node ISMP ports can be daisy-chained from the RSA ISMP port. See the RSA documentation listed in Related information for the number of nodes supported.

The management VLAN connects to non-node and other devices that do not have another hardware control point such as an RSA through the APC MasterSwitch (apc01) Ethernet port. Power cables connect the devices to the APC MasterSwitch. The management VLAN connects to blade servers through the BladeCenter chassis management module (mm01), and to eServer 325 through the baseboard management controller (BMC).


Applications usually run on the public VLAN, which connects to the servers through Ethernet ports. Configuration for a public VLAN is flexible and can be defined by the system administrator. See Node hardware attributes for example node attribute definitions corresponding to Figure 1.


CSM hardware control configuration for xSeries, BladeCenter, and eServer 325 Linux nodes


Figure 3. CSM hardware control configuration for xSeries, BladeCenter, and eServer 325 Linux nodes


Linux node attributes example


Figure 4 shows the relationship between the CSM node database attributes and the internal hardware names used in Figure 3. For remote power and remote console to work as expected, this matching of database attribute names to the internal hardware values must be correct for all management processors (ISMPs), remote supervisor adapters (RSAs), management modules, APCs, BMCs, and console servers in the CSM cluster.


CSM hardware control attribute values for Linux nodes


Figure 4. CSM hardware control attribute values for Linux nodes



Conceptual diagram: Linux on pSeries

Figure 5 shows the hardware and networking configuration required for using CSM hardware control with HMC-attached pSeries servers running Linux. The HMC-attached pSeries server in the diagram is a single piece of hardware that has been partitioned by HMCs into 16 LPARs (nodes). The management server connects to the management and cluster VLANs through Ethernet adapters. Nodes on HMC-attached pSeries servers must be connected to the cluster VLAN and directly or indirectly to an HMC. Configuration for a public VLAN is flexible and can be defined by the system administrator. See Node hardware attributes for example node attribute definitions.


CSM hardware control hardware configuration for Linux on pSeries


Figure 5. CSM hardware control hardware configuration for Linux on pSeries



Linux on pSeries node attributes example


Figure 6 is a detailed view of some nodes from Figure 5. The diagram shows the relationship between the CSM node database attributes and the internal hardware names used in Figure 3. For remote power and remote console to work as expected, this matching of database attribute names to the internal hardware values must be correct for all management processors (MPs), management processor adapters (MPAs), and console serial providers in the cluster.

CSM hardware control database attribute values for Linux nodes


Figure 6. CSM hardware control database attribute values for Linux nodes



Conceptual diagram: mixed cluster


Figure 7 shows the hardware and networking configuration required for using CSM hardware control in a mixed cluster with pSeries, SP Nodes, and p660 nodes running AIX; and xSeries, the eServer 325, and BladeCenter servers running Linux. The HMC-attached pSeries server has been partitioned by an HMC into 10 LPARs (nodes).


The management server shown in the diagram connects to the management and cluster VLANs through Ethernet adapters. The console servers (mrv01, mrv02) connect to the management VLAN through Ethernet adapters, to the xSeries servers through serial (COM) ports, and to BladeCenter HS20-8678 blade servers through the Cluster 1350 Serial Port Module option. BladeCenter HS20 (other than HS20-8678), blade servers do not require an attached console server. They provide remote console independently using the Serial Over LAN feature


The IBM Cluster 1350 Serial Port Module is an optional part that must be ordered separately to connect BladeCenter HS20-8678 blade servers to an MRV console server. This connection provides rconsole command function for BladeCenter servers. See CSM for AIX 5L and Linux: Administration GuideCSM for AIX 5L and Linux: Administration Guide for the configuration required for this alternative to using a Web browser for BladeCenter remote console function.

The management VLAN connects to the IBM Remote Supervisor Adapter (RSA) in select xSeries servers. The servers must be connected to the cluster VLAN through their first Ethernet adapters (eth0), and directly or indirectly to an RSA. An RSA connects to its node internal service management processor (ISMP) port, and up to nine node ISMP ports can be daisy-chained from the RSA ISMP port. See the RSA documentation listed in Related information for the number of nodes supported.


The management VLAN connects to non-node and other devices that do not have another hardware control point such as an RSA through the APC MasterSwitch (apc01) Ethernet port. Power outlets and cables connect the devices to the APC MasterSwitch. The management VLAN connects to the BladeCenter blade servers through the management module (mm01) on the BladeCenter chassis, and to the eServer 325 through the BMC.


Applications usually run on the cluster VLAN, which connects to the servers through Ethernet ports. Configuration for a public VLAN is flexible and can be defined by the system administrator. See Node hardware attributes for example node attribute definitions corresponding to Figure 1.

CSM hardware configuration for pSeries, SP Nodes, p660 nodes, xSeries, eServer 325, and BladeCenter


Figure 7. CSM hardware control configuration for pSeries, SP Nodes, p660 nodes, xSeries, eServer 325, and BladeCenter



Mixed cluster node attributes example


Figure 8 and Figure 9 show the relationship between the CSM node database attributes and the internal hardware names used in Figure 3. For remote power and remote console to work as expected, this matching of database attribute names to the internal hardware values must be correct for all HMCs, ISMPs, RSAs, APCs, BMCs, management modules, and console servers in the cluster.


CSM hardware control attribute values for AIX and Linux nodes

Figure 8. CSM hardware control attribute values for AIX and Linux nodes



CSM hardware control attribute values for AIX and Linux nodes (continued)


Figure 9. continued, CSM hardware control attribute values for AIX and Linux nodes


 6 views