#
2008.09.30 凌晨1:30，可爱的女儿出生。
给她起名叫歆怿，即开开心心，高高兴兴的意思。
希望她一定过得比她爸爸好，活得比她爸爸精彩。
转：
http://news.csdn.net/n/20060801/93169.html
这篇文章中，我们选用MySQL 4.0.2-alpha与PostgreSQL 7.2进行比较，因为MySQL 4.0.2-alpha开始支持事务的概念，因此这样的比较对于MySQL应该较为有利。
我们这样的比较不想仅仅成为一份性能测试报告，因为至少从我个人来看，对于一个数据库，稳定性和速度并不能代表一切。对于一个成熟的数据库，稳定性肯定会日益提供。而随着硬件性能的飞速提高，速度也不再是什么太大的问题。
一、两者的共同优势
这两个产品都属于开放源码的一员，性能和功能都在高速地提高和增强。MySQL AB的人们和PostgreSQL的开发者们都在尽可能地把各自的数据库改得越来越好，所以对于任何商业数据库使用其中的任何一个都不能算是错误的选择。
二、两者不同的背景
MySQL的背后是一个成熟的商业公司，而PostgreSQL的背后是一个庞大的志愿开发组。这使得MySQL的开发过程更为慎重，而PostgreSQL的反应更为迅速。
这样的两种背景直接导致了各自固有的优点和缺点。
三、MySQL的主要优点
1、首先是速度，MySQL通常要比PostgreSQL快得多。MySQL自已也宣称速度是他们追求的主要目标之一，基于这个原因，MySQL在以前的文档中也曾经说过并不准备支持事务和触发器。但是在最新的文档中，我们看到MySQL 4.0.2-alpha已经开始支持事务，而且在MySQL的TODO中，对触发器、约束这样的注定会降低速度的功能也列入了日程。但是，我们仍然有理由相信，MySQL将有可能一直保持速度的优势。
2、MySQL比PostgreSQL更流行，流行对于一个商业软件来说，也是一个很重要的指标，流行意味着更多的用户，意味着经受了更多的考验，意味着更好的商业支持、意味着更多、更完善的文档资料。
3、与PostgreSQL相比，MySQL更适宜在Windows环境下运行。MySQL作为一个本地的Windows应用程序运行(在NT/Win2000/WinXP下，是一个服务)，而PostgreSQL是运行在Cygwin模拟环境下。PostgreSQL在Windows下运行没有MySQL稳定，应该是可以想象的。
4、MySQL使用了线程，而PostgreSQL使用的是进程。在不同线程之间的环境转换和访问公用的存储区域显然要比在不同的进程之间要快得多。
5、MySQL可以适应24/7运行。在绝大多数情况下，你不需要为MySQL运行任何清除程序。PostgreSQL目前仍不完全适应24/7运行，这是因为你必须每隔一段时间运行一次VACUUM。
6、MySQL在权限系统上比PostgreSQL某些方面更为完善。PostgreSQL只支持对于每一个用户在一个数据库上或一个数据表上的INSERT、SELECT和UPDATE/DELETE的授权，而MySQL允许你定义一整套的不同的数据级、表级和列级的权限。对于列级的权限，PostgreSQL可以通过建立视图，并确定视图的权限来弥补。MySQL还允许你指定基于主机的权限，这对于目前的PostgreSQL是无法实现的，但是在很多时候，这是有用的。
7、由于MySQL 4.0.2-alpha开始支持事务的概念，因此事务对于MySQL不再仅仅成为劣势。相反，因为MySQL保留无事务的表类型。这就为用户提供了更多的选择。
8、MySQL的MERGE表提供了一个独特管理多个表的方法。
9、MySQL的myisampack可以对只读表进行压缩，此后仍然可以直接访问该表中的行。
四、PostgreSQL的主要优点：
1、对事务的支持与MySQL相比，经历了更为彻底的测试。对于一个严肃的商业应用来说，事务的支持是不可或缺的。
2、MySQL对于无事务的MyISAM表。采用表锁定，一个长时间运行的查询很可能会长时间地阻碍对表的更新。而PostgreSQL不存在这样的问题。
3、PostgreSQL支持存储过程，而目前MySQL不支持，对于一个严肃的商业应用来说，作为数据库本身，有众多的商业逻辑的存在，此时使用存储过程可以在较少地增加数据库服务器的负担的前提下，对这样的商业逻辑进行封装，并可以利用数据库服务器本身的内在机制对存储过程的执行进行优化。此外存储过程的存在也避免了在网络上大量的原始的SQL语句的传输，这样的优势是显而易见的。
4、对视图的支持，视图的存在同样可以最大限度地利用数据库服务器内在的优化机制。而且对于视图权限的合理使用，事实上可以提供行级别的权限，这是MySQL的权限系统所无法实现的。
5、对触发器的支持，触发器的存在不可避免的会影响数据库运行的效率，但是与此同时，触发器的存在也有利于对商业逻辑的封装，可以减少应用程序中对同一商业逻辑的重复控制。合理地使用触发器也有利于保证数据的完整性。
6、对约束的支持。约束的作用更多地表现在对数据完整性的保证上，合理地使用约束，也可以减少编程的工作量。
7、对子查询的支持。虽然在很多情况下在SQL语句中使用子查询效率低下，而且绝大多数情况下可以使用带条件的多表连接来替代子查询，但是子查询的存在在很多时候仍然不可避免。而且使用子查询的SQL语句与使用带条件的多表连接相比具有更高的程序可读性。
8、支持R-trees这样可扩展的索引类型，可以更方便地处理一些特殊数据。
9、PostgreSQL可以更方便地使用UDF(用户定义函数)进行扩展。
五、那么我究竟应该使用MySQL还是PostgreSQL
这个问题很难说得清，而且事实上除了MySQL和PostgreSQL外，使用Oracle、Sybase、Informix等也是明智的选择。如何你确定只在MySQL和PostgreSQL中进行选择，以下规则总是有效的。
1、如果你的操作系统是Windows，你应该使用MySQL。
2、如果你对数据库并不了十分了解，甚至不知道事务、存储过程等究竟是什么，你应该使用MySQL。
3、如果你的应用对数据的完整性和严肃性要求不高，但是追求处理的高速度。例如是一个论坛和社区，你应该使用MySQL。
4、你的应用是一个严肃的商业应用，对数据完整性要求很高。而且你希望对一些商业数据逻辑进行很好的封装，例如是一个网上银行，你应该使用PostgreSQL。
5、你的应用处理的是地理数据，由于R-TREES的存在，你应该使用PostgreSQL。
6、你是一个数据库内核的狂热爱好者，你甚至希望拥有你自己版本的数据库，毫无疑问，你必须使用PostgreSQL，没准下一个PostgreSQL版本中某一个模块的作者就是你。
六、后记
以上只是作者从自己的理解尽量客观公正地评价MySQL和PostgreSQL的优劣。其中的带有倾向性的意见只代表作者个人观点，有关这两个数据库，欢迎广大朋友提出自己的看法。
http://en.wikipedia.org/wiki/VTP
VLAN Trunking Protocol (VTP) is a Cisco proprietary Layer 2 messaging protocol that manages the addition, deletion, and renaming of VLANs on a network-wide basis. Virtual Local Area Network (VLAN) Trunk Protocol (VTP) reduces administration in a switched network. When you configure a new VLAN on one VTP server, the VLAN is distributed through all switches in the domain. This reduces the need to configure the same VLAN everywhere. To do this VTP carries VLAN information to all the switches in a VTP domain. VTP advertisements can be sent over ISL, 802.1q, IEEE 802.10 and LANE trunks. VTP traffic is sent over the management VLAN (VLAN1), so all VLAN trunks must be configured to pass VLAN1. VTP is available on most of the Cisco Catalyst Family products.
You can configure a switch to operate in any one of these VTP modes:
-
Server—In VTP server mode, you can create, modify, and delete VLANs and specify other configuration parameters, such as VTP version and VTP pruning, for the entire VTP domain. VTP servers advertise their VLAN configuration to other switches in the same VTP domain and synchronize their VLAN configuration with other switches based on advertisements received over trunk links. VTP server is the default mode.
-
Client—VTP clients behave the same way as VTP servers, but you cannot create, change, or delete VLANs on a VTP client.
-
Transparent—VTP transparent switches do not participate in VTP. A VTP transparent switch does not advertise its VLAN configuration and does not synchronize its VLAN configuration based on received advertisements, but transparent switches do forward VTP advertisements that they receive out their trunk ports in VTP Version 2.
-
Off (configurable only in CatOS switches)—In the three described modes, VTP advertisements are received and transmitted as soon as the switch enters the management domain state. In the VTP off mode, switches behave the same as in VTP transparent mode with the exception that VTP advertisements are not forwarded.
http://en.wikipedia.org/wiki/Spanning_tree_protocol
The Spanning Tree Protocol is an OSI layer-2 protocol that ensures a loop-free topology for any bridged LAN. It is based on an algorithm invented by Radia Perlman while working for Digital Equipment Corporation. Spanning tree allows a network design to include spare (redundant) links to provide automatic backup paths if an active link fails, without the danger of bridge loops, or the need for manual enabling/disabling of these backup links. Bridge loops must be avoided because they result in flooding the network.
The Spanning Tree Protocol (STP), is defined in the IEEE Standard 802.1D. As the name suggests, it creates a spanning tree within a mesh network of connected layer-2 bridges (typically Ethernet switches), and disables those links that are not part of the tree, leaving a single active path between any two network nodes.
http://en.wikipedia.org/wiki/VLAN
A virtual LAN, commonly known as a VLAN, is a group of hosts with a common set of requirements that communicate as if they were attached to the Broadcast domain, regardless of their physical location. A VLAN has the same attributes as a physical LAN, but it allows for end stations to be grouped together even if they are not located on the same network switch. Network reconfiguration can be done through software instead of physically relocating devices.
Uses
VLANs are created to provide the segmentation services traditionally provided by routers in LAN configurations. VLANs address issues such as scalability, security, and network management. Routers in VLAN topologies provide broadcast filtering, security, address summarization, and traffic flow management. By definition, switches may not bridge IP traffic between VLANs as it would violate the integrity of the VLAN broadcast domain.
This is also useful if one wants to create multiple Layer 3 networks on the same Layer 2 switch. For example if a DHCP server (which will broadcast its presence) were plugged into a switch it would serve anyone on that switch that was configured to do so. By using VLANs you easily split the network up so some hosts won't use that server and default to Link-local addresses.
Virtual LANs are essentially Layer 2 constructs, compared with IP subnets which are Layer 3 constructs. In a LAN employing VLANs, a one-to-one relationship often exists between VLANs and IP subnets, although it is possible to have multiple subnets on one VLAN or have one subnet spread across multiple VLANs. Virtual LANs and IP subnets provide independent Layer 2 and Layer 3 constructs that map to one another and this correspondence is useful during the network design process.
By using VLAN, one can control traffic patterns and react quickly to relocations. VLANs provide the flexibility to adapt to changes in network requirements and allow for simplified administration.
Motivation
In a legacy network, users were assigned to networks based on geography and were limited by physical topologies and distances. VLANs can logically group networks so that the network location of users is no longer so tightly coupled to their physical location. Technologies able to implement VLANs are:
Asynchronous Transfer Mode (ATM)
Fiber Distributed Data Interface (FDDI)
Fast Ethernet
Gigabit Ethernet
10 Gigabit Ethernet
HiperSockets
Protocols and design
The protocol most commonly used today in configuring virtual LANs is IEEE 802.1Q. The IEEE committee defined this method of multiplexing VLANs in an effort to provide multivendor VLAN support. Prior to the introduction of the 802.1Q standard, several proprietary protocols existed, such as Cisco's ISL (Inter-Switch Link, a variant of IEEE 802.10) and 3Com's VLT (Virtual LAN Trunk). ISL is no longer supported by Cisco.
Both ISL and IEEE 802.1Q tagging perform explicit tagging as the frame is tagged with VLAN information explicitly. ISL uses an external tagging process that does not modify the existing Ethernet frame whereas 802.1Q uses an internal tagging process that does modify the Ethernet frame. This internal tagging process is what allows IEEE 802.1Q tagging to work on both access and trunk links, because the frame appears to be a standard Ethernet frame.
The IEEE 802.1Q header contains a 4-byte tag header containing a 2-byte tag protocol identifier (TPID) and a 2-byte tag control information (TCI). The TPID has a fixed value of 0x8100 that indicates that the frame carries the 802.1Q/802.1p tag information. The TCI contains the following elements:
Three-bit user priority
One-bit canonical format indicator (CFI)
Twelve-bit VLAN identifier (VID)-Uniquely identifies the VLAN to which the frame belongs
The 802.1Q standard can create an interesting scenario on the network. Recalling that the maximum size for an Ethernet frame as specified by IEEE 802.3 is 1518 bytes, this means that if a maximum-sized Ethernet frame gets tagged, the frame size will be 1522 bytes, a number that violates the IEEE 802.3 standard. To resolve this issue, the 802.3 committee created a subgroup called 802.3ac to extend the maximum Ethernet size to 1522 bytes. Network devices that do not support a larger frame size will process the frame successfully but may report these anomalies as a "baby giant."
Inter-Switch Link (ISL) is a Cisco proprietary protocol used to interconnect multiple switches and maintain VLAN information as traffic travels between switches on trunk links. This technology provides one method for multiplexing bridge groups (VLANs) over a high-speed backbone. It is defined for Fast Ethernet and Gigabit Ethernet, as is IEEE 802.1Q. ISL has been available on Cisco routers since Cisco IOS Software Release 11.1.
With ISL, an Ethernet frame is encapsulated with a header that transports VLAN IDs between switches and routers. ISL does add overhead to the packet as a 26-byte header containing a 10-bit VLAN ID. In addition, a 4-byte CRC is appended to the end of each frame. This CRC is in addition to any frame checking that the Ethernet frame requires. The fields in an ISL header identify the frame as belonging to a particular VLAN.
A VLAN ID is added only if the frame is forwarded out a port configured as a trunk link. If the frame is to be forwarded out a port configured as an access link, the ISL encapsulation is removed.
Early network designers often configured VLANs with the aim of reducing the size of the collision domain in a large single Ethernet segment and thus improving performance. When Ethernet switches made this a non-issue (because each switch port is a collision domain), attention turned to reducing the size of the broadcast domain at the MAC layer. Virtual networks can also serve to restrict access to network resources without regard to physical topology of the network, although the strength of this method remains debatable as VLAN Hopping [1] is a common means of bypassing such security measures.
Virtual LANs operate at Layer 2 (the data link layer) of the OSI model. Administrators often configure a VLAN to map directly to an IP network, or subnet, which gives the appearance of involving Layer 3 (the network layer). In the context of VLANs, the term "trunk" denotes a network link carrying multiple VLANs, which are identified by labels (or "tags") inserted into their packets. Such trunks must run between "tagged ports" of VLAN-aware devices, so they are often switch-to-switch or switch-to-router links rather than links to hosts. (Note that the term 'trunk' is also used for what Cisco calls "channels" : Link Aggregation or Port Trunking). A router (Layer 3 device) serves as the backbone for network traffic going across different VLANs.
On Cisco devices, VTP (VLAN Trunking Protocol) maintains VLAN configuration consistency across the entire network. VTP uses Layer 2 trunk frames to manage the addition, deletion, and renaming of VLANs on a network-wide basis from a centralized switch in the VTP server mode. VTP is responsible for synchronizing VLAN information within a VTP domain and reduces the need to configure the same VLAN information on each switch.
VTP minimizes the possible configuration inconsistencies that arise when changes are made. These inconsistencies can result in security violations, because VLANs can crossconnect when duplicate names are used. They also could become internally disconnected when they are mapped from one LAN type to another, for example, Ethernet to ATM LANE ELANs or FDDI 802.10 VLANs. VTP provides a mapping scheme that enables seamless trunking within a network employing mixed-media technologies.
VTP provides the following benefits:
VLAN configuration consistency across the network
Mapping scheme that allows a VLAN to be trunked over mixed media
Accurate tracking and monitoring of VLANs
Dynamic reporting of added VLANs across the network
Plug-and-play configuration when adding new VLANs
As beneficial as VTP can be, it does have disadvantages that are normally related to the Spanning Tree Protocol (STP) as a bridging loop propagating throughout the network can occur. Cisco switches run an instance of STP for each VLAN, and since VTP propagates VLANs across the campus LAN, VTP effectively creates more opportunities for a bridging loop to occur.
Before creating VLANs on the switch that will be propagated via VTP, a VTP domain must first be set up. A VTP domain for a network is a set of all contiguously trunked switches with the same VTP domain name. All switches in the same management domain share their VLAN information with each other, and a switch can participate in only one VTP management domain. Switches in different domains do not share VTP information.
Using VTP, each Catalyst Family Switch advertises the following on its trunk ports:
Management domain
Configuration revision number
Known VLANs and their specific parameters
Establishing VLAN memberships
The two common approaches to assigning VLAN membership are as follows:
Static VLANs
Dynamic VLANs
Static VLANs are also referred to as port-based VLANs. Static VLAN assignments are created by assigning ports to a VLAN. As a device enters the network, the device automatically assumes the VLAN of the port. If the user changes ports and needs access to the same VLAN, the network administrator must manually make a port-to-VLAN assignment for the new connection.
Dynamic VLANs are created through the use of software packages such as CiscoWorks 2000. With a VLAN Management Policy Server VMPS, an administrator can assign switch ports to VLANs dynamically based on information such as the source MAC address of the device connected to the port or the username used to log onto that device. As a device enters the network, the device queries a database for VLAN membership. See also FreeNAC which implements a VMPS server.
Port-based VLANs
With port-based VLAN membership, the port is assigned to a specific VLAN independent of the user or system attached to the port. This means all users attached to the port should be members in the same VLAN. The network administrator typically performs the VLAN assignment. The port configuration is static and cannot be automatically changed to another VLAN without manual reconfiguration.
As with other VLAN approaches, the packets forwarded using this method do not leak into other VLAN domains on the network. After a port has been assigned to a VLAN, the port cannot send to or receive from devices in another VLAN without the intervention of a Layer 3 device.
The device that is attached to the port likely has no understanding that a VLAN exists. The device simply knows that it is a member of a subnet and that the device should be able to talk to all other members of the subnet by simply sending information to the cable segment. The switch is responsible for identifying that the information came from a specific VLAN and for ensuring that the information gets to all other members of the VLAN. The switch is further responsible for ensuring that ports in a different VLAN do not receive the information.
This approach is quite simple, fast, and easy to manage in that there are no complex lookup tables required for VLAN segmentation. If port-to-VLAN association is done with an application-specific integrated circuit (ASIC), the performance is very good. An ASIC allows the port-to-VLAN mapping to be done at the hardware level.
Protocol Based VLANs
This section needs additional citations for verification.
Please help improve this article by adding reliable references. Unsourced material may be challenged and removed. (February 2008)
In a protocol based VLAN enabled switch, traffic is forwarded through ports based on protocol. Essentially user tries to segregate or forward a particular protocol traffic from a port using the protocol based VLANs, traffic from any other protocol is not forwarded on the port. For example, if you have connected a host, pumping ARP traffic on the switch at port 10, connected a Lan pumping IPX traffic to the port 20 of the switch and connected a router pumping IP traffic on port 30. then if you define a protocol based VLAN supporting IP and including all the three ports 10, 20 and 30 then IP packets can be forwarded to the ports 10 and 20 also , but ARP traffic will not get forwarded to the ports 20 and 30, similarly IPX traffic will not get forwarded to ports 10 and 30.
http://en.wikipedia.org/wiki/Link_Layer_Discovery_Protocol
The Link Layer Discovery Protocol or LLDP is a vendor-neutral Layer 2 protocol that allows a network device to advertise its identity and capabilities on the local network. The protocol was formally ratified as IEEE standard 802.1AB-2005 in May 2005. It supersedes proprietary protocols like Cisco Discovery Protocol, Extreme Discovery Protocol and Nortel Discovery Protocol (also known as SONMP).
Information gathered with LLDP are stored in the device and can be queried using Simple Network Management Protocol. The topology of a LLDP-enabled network can be discovered by crawling the hosts and querying this database. Information that can be retrieved include:
system name and description
port name and description
VLAN name
IP management address
system capabilities (switching, routing, etc.)
MAC/PHY information
MDI power
link aggregation
Support
LLDP is still young but is supported on various types of equipment:
HP ProCurve switches and routers
Extreme switches and routers
Nortel 55x0 and 425 series
Allied Telesis switches and routers
Cisco switchs and routers with recent IOS
Alcatel-Lucent switches with AOS > 6.3.1
Juniper EX series switches
AASTRA 9480i (35i) and 675i series VoIP phones
Enterasys Secure Networks
如果所有设备都支持LLDP，那拓扑发现程序就很容易写了。
http://en.wikipedia.org/wiki/Cisco_Discovery_Protocol
The Cisco Discovery Protocol (CDP) is a proprietary layer 2 network protocol developed by Cisco Systems that runs on most Cisco equipment and is used to share information about other directly connected Cisco equipment such as the operating system version and IP address. CDP can also be used for On-Demand Routing (ODR), which is a method of including routing information in CDP announcements so that dynamic routing protocols do not need to be used in simple networks.
Cisco devices send CDP announcements to the multicast destination address 01-00-0c-cc-cc-cc (also used for other Cisco proprietary protocols such as VTP). CDP announcements (if supported and configured in IOS) are sent by default every 60 seconds on interfaces that support Subnetwork Access Protocol (SNAP) headers, including Ethernet, Frame Relay and ATM. Each Cisco device that supports CDP stores the information received from other devices in a table that can be viewed using the show cdp neighbors command. The CDP table's information is refreshed each time an announcement is received, and the holdtime for that entry is reset. The holdtime specifies how long an entry in the table will be kept - if no announcements are received from a device and the holdtime timer expires for that entry, the device's information is discarded (default 180 seconds).
The information contained in CDP announcements varies by the type of device and the version of the operating system running on it. Information contained includes the operating system version, hostname, every address for every protocol configured on the port where CDP frame is sent eg. IP address, the port identifier from which the announcement was sent, device type and model, duplex setting, VTP domain, native VLAN, power draw (for Power over Ethernet devices), and other device specific information. The details contained in these announcements is easily extended due to the use of the type-length-value (TLV) frame format. See external links for a technical definition.
HP removed support for sending CDP from HP Procurve products shipping after February 2006 and all future software upgrades. Receiving CDP and showing neighbor information is still supported. CDP support was replaced with LLDP.
Conclusions and Lessons Learned
What are the key lessons we have learned? In no particular order:
Address the provision of systems management in prioritized, manageable units of work. Don't try to do everything at once.
Manage the rollout of your systems management application just like any other implementation. After all, availability and integrity of your management application should ideally exceed that of the most critical component that it manages.
Get buy in from all the stakeholders in the process, from Management to Shift Operators.
Think about who will use the tool. You probably don't want to send alerts regarding printer failures to your DBA team. Similarly it's probably not a good idea to send arcane messages about network topology changes to application support teams. Prioritize system alerts and trim out noise.
Don't use it a stick to beat developers, network admin or systems admin staff. If your network management tool highlights a problem, use that information as a justification to provide the resources to fix it.
Do your research. Adopting an Open Source solution requires just as much rigor in the selection and evaluation process as a proprietary solution. By all means download your candidate solution and try it out, but don't allow a machine under a Systems Administrator's desk to become a mission critical component.
It's not been a totally smooth ride. We had repeated problems with memory leaks within the Java virtual machine (admittedly, not OpenNMS's fault). We also had a few nasty problems with corruption of OpenNMS's back-end database, which are now fixed. There were also a lot of "d'oh!" moments along the way, as we got up to speed with what is a pretty complex application. None of these problems ever seemed like show stoppers at the time. This had much to do with help extended by the development team and user community, to whom we extend our thanks.
Why OpenNMS?
OpenNMS checked a lot of these boxes. It was (mostly) java, so we could run it on our Sun hardware. OpenNMS was already running in environments an order of magnitude larger than ours. It had a lot of the enterprise level features absent from other Open Source products. There were documents available on the Internet [1],[2] that pointed to its extensibility. It was based on a lot of familiar components (tomcat, postgres, rrdtool). Finally, in Open Source terms, it was a relatively mature product.
We took a cautious approach deploying OpenNMS.
Simplest to replace, and therefore first to go were the existing network monitoring products. Only after a month of parallel running with OpenNMS did we decommission our existing solutions.
Second to go were the diverse collection of emails that were sent by applications or batch jobs. We replaced the destination email addresses with some mailboxes that delivered the notifications directly into OpenNMS. This turned out to be a bigger win than we'd expected. By having a central point where application alerts could be received and processed, we revealed hidden issues with applications that had existed for weeks or months.
This was painful at first. The respective teams were often uncomfortable in having their problems aired to the world. Once we started to address these problems, however, and the frequency of the alerts started to reduce, we started to see real benefits. The operations team had a single console to monitor applications, and we could reduce the number of application support staff on call.
The next target was system performance data collected by our existing tools. That which could be readily moved into OpenNMS went quickly. Platform specific data collectors (such as those which collected from Microsoft hosts using WMI) had any important alerts channeled in to OpenNMS.
Our current focus, now that we believe our OpenNMS installation is mature, is back in application space. We are extending the end-to-end monitoring capabilities of OpenNMS to our web services providers. We are also starting to use it to retrieve instrumentation data directly from applications themselves, as well as their hosts.
Did We Meet Our Requirements?
Here's how things shook out:
Platform independence: Yes. OpenNMS can run on spare hardware. But it's not a good idea. A year after our first rollout of OpenNMS, we moved from a shared SUN Ultrasparc 2 machine to a dedicated dual Xeon machine running RedHat Advanced Server.
Performance: Yes. We are comfortable in that there will always be users pushing the scalability of OpenNMS much harder than we are.
Enterprise Level Features: A cautious yes. OpenNMS met our initial requirements, but also quickly highlighted new ones. Some customers are never satisfied.
Rationalize Support Roles: Yes. OpenNMS is now the single point for the distribution of all actionable network, server and application events. This does need to be constantly policed, to ensure that non-standard notification paths do not creep in again.
Reduce Tasks: A cautious yes. In general, the operator's load has lessened, if only because it has reduced the numbers of open windows on their desktops.
Extensibility: Yes. OpenNMS has proved to be highly extensible.
Low cost of entry: We deployed OpenNMS with minimal capital outlay. We believe that the subsequent people based operational costs have been roughly equivalent to those of a commercial solution.
Longevity: We seem to have backed a product with "legs." The mailing lists [3] are as busy as ever and new features are being added to OpenNMS faster than we can make use of them.
The "sweet spot" for OpenNMS seems to be about as wide as any Open Source solution and getting bigger by the month. We look forward to enhancements in the web user interface, a new JMX based data collector and support for event correlation in the near future.
Why Do We Need a Systems Management Tool?
Current trends in the IT world continue to accelerate the rate of change in every area. Applications, server platforms and networks are no longer the slow moving entities they once were. They are subject to change on an almost daily basis. In this environment, it becomes more and more important for the IT Operations team to quickly detect, and respond to changes, or anomalous events.
My employer is a relatively new business. Applications would be customized packages, and a large section of its core IT systems would be outsourced. Slowly, those package based solutions morphed into custom applications and, for a variety of reasons, these outsourced systems were brought back in-house a couple of years ago. This presented those of us in the IT department with some interesting challenges. One of those challenges was how to go about managing our newly re-acquired IT infrastructure and applications.
When we first decided to move our core systems from an outsourced to an in-house IT Operations Department, our requirements were limited. Checking the availability of some services and the load on the network and key servers was about as much as we thought we needed.
It became obvious over time that this was rather optimistic. Each new service added seemed to result in a new management tool being installed on a System Administrator's workstation. At one point we had three separate network monitoring systems, three separate performance management tools and a plethora different scripts, web pages and command line tools. The DBA team had one tool, the Network Admins another, the Unix and Windows teams yet another. We sent out critical alerts by email, pager, and SMS, often to completely inappropriate people.
The company was growing, and it looked like it was beginning to need a grown-up systems management tool, but which one?
What Do We Expect from a Systems Management Application?
There is definitely a "sweet spot" for systems management applications. Some are suited to smaller environments, others are most definitely suited to enterprise scale environments with more demanding requirements. Unsurprisingly the enterprise scale products often come with enterprise scale price tags and learning curves.
We had a few key requirements:
Platform independence: Our network management system would have to run on available hardware (at the time, SPARC/Solaris).
Performance: Any solution would need to scale from a few hundred nodes to a few thousand nodes.
Enterprise level features: We required at least SNMP trap management, configurable alert escalation and availability and performance reports for the management team.
Rationalize support roles: We needed to be able to take individuals out of the process. That meant an end to emails sent by systems to developers in the middle of the night. Our operations team needed to be the first contact for every event.
Reduce tasks: It would need to lighten the burden on the Operations Team, not increase it.
Extensibility: Previous experience indicated that there was no such thing as a complete solution.
Low cost of entry: It needed to replace a portfolio of Open Source products.
Longevity: Some Open Source products seem to wither on the vine with no apparent cause, or fragment through disagreements between developers. Commercial products too are subject to the vagaries of the market.
摘要: package afu.mymail;
import java.io.*;
import javax.mail.internet.*;
import javax.mail.*;
import java.util.*;
public class RecieveMail
{
...
阅读全文
摘要: package afu.proxy;
import java.net.*;
import java.io.*;
import org.apache.commons.httpclient.*;
import org.apache.commons.httpclient.methods.*;
public class&nb...
阅读全文
N/A是指：Not Applicable。不是Not Available 的缩写。
是指表格中空出的地方要填的一栏，与你的情况不合。N/A是你填进去的字，不是原有印在上面的。比如表格要你填state或prorinve，但你的国家或你住的地方，没有“省”这个概念，如有的国家，国家下面就是“区”了。还有，有的表格问你有几个孩子，你连结婚都没有结，自然填N/A。
见下面N/A即Not Applicable的释意：
A commonly used abbreviation in the English language for the lack of data in a form or table field, because it does not apply to the situation.
Ethernet Frame Formats:
Ethernet (a.k.a. Ethernet II)
+---------+---------+---------+----------
| Dst | Src | Type | Data...
+---------+---------+---------+----------
<-- 6 --> <-- 6 --> <-- 2 --> <-46-1500->
Type 0x80 0x00 = TCP/IP
Type 0x06 0x00 = XNS
Type 0x81 0x37 = Novell NetWare
802.3
+---------+---------+---------+----------
| Dst | Src | Length | Data...
+---------+---------+---------+----------
<-- 6 --> <-- 6 --> <-- 2 --> <-46-1500->
802.2 (802.3 with 802.2 header)
+---------+---------+---------+-------+-------+-------+----------
| Dst | Src | Length | DSAP | SSAP |Control| Data...
+---------+---------+---------+-------+-------+-------+----------
<- 1 -> <- 1 -> <- 1 -> <-43-1497->
SNAP (802.3 with 802.2 and SNAP headers)
+---------+---------+---------+-------+-------+-------+-----------+---------+-----------
| Dst | Src | Length | 0xAA | 0xAA | 0x03 | Org Code | Type | Data...
+---------+---------+---------+-------+-------+-------+-----------+---------+-----------
<-- 3 --> <-- 2 --> <-38-1492->
Ethernet中存在这四种Frame的格式，如果不能很好的区分他们，那么肯定会造成网络的混乱，
现实中网络设备可以很好的识别它们，那么网络设备又是如何识别的呢?
(1) 如何区分EthernetII与其他格式的帧
如果帧头跟随source mac地址的2 bytes的值大于1500则此Frame为EthernetII格式的。否则就是其他格式的帧。
(2)其他帧格式的区别
接着比较紧接着的两bytes如果为0xFFFF则为Novell Ethernet 类型的Frame
如果为0xAAAA则为Ethernet SNAP格式的Frame ，如果都不是则为Ethernet
802.3/802.2格式的帧
在/etc/profile加入
export JAVA_HOME=/usr/java/jdk1.6.0_06
export PATH=$JAVA_HOME/bin:$CATALINA_HOME/bin:$PATH
export TOMCAT_HOME=/software/apache-tomcat-6.0.16
export BASEDIR=/software/apache-tomcat-6.0.16
export CATALINA_BASE=/software/apache-tomcat-6.0.16
export CATALINA_HOME=/software/apache-tomcat-6.0.16
export CATALINA_TMPDIR=/software/apache-tomcat-6.0.16/temp
重启后，用java -version查看
[root@afunms bin]# java -version
java version "1.6.0_06"
Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
Java HotSpot(TM) Client VM (build 10.0-b22, mixed mode, sharing)