Showing posts with label Suse Linux. Show all posts
Showing posts with label Suse Linux. Show all posts

Changing default gateway in SuSE Linux


Adding default Gateway in Linux SUSE

To change the default route permanently in SuSe Linux, make an entry in /etc/sysconfig/network/routes file.

For example, to make 192.168.10.1 as default route, add the following line into /etc/sysconfig/network/routes file. 

default 192.168.2.1 - -

Using route command:

To route all the traffic via 192.168.1.1 gateway connected via eth1 network interface:
# route add default gw 192.168.1.1 eth1

To view routes configured:

# netstat -rn 

kblockd Process - High Utilization in Linux - Quick View

I  have came across the situation where multiple kblockd process are utilizing the CPU heavily and causing server load high in Linux servers. I was wondered what is kblockd and why it is taking high CPU utilization. But there is not much information available in internet about kblockd. After lot of  research, the below is what I learned.


What is kblockd?

In a general, the kblockd kernel threads are responsible for performing low-level disk operations.


Why kblockd processes are heavily utilizing the CPU which causing server load?

A high utilization of these could indicate that the server IO queue is backed up and the server is not managing to perform its disk writes quick enough. Most of the times, At that point, the SD drivers fails the IO and fails it to EXT3, which then aborts the journal for safety reasons. So when it is middle of transaction, it forgets about it and retrying to rollback. Also the kblockd message is a symptom of  "server running low on memory and starting to fail normal kernel memory allocations".

Most of the times this is a sign of pathological behavior by the kernel or merely a symptom of an overloaded server, depends on the workload of the server and its hardware. Please note that there is always a potential for hangs when something can't allocate memory.


What can be done to resolve this issue?

For now, I don't find any immediate resolution to fix this issue. However keeping your kernel version and block device driver modules up to date might help fixing this issue. Also Upgrading the Linux server to the latest available service pack level is recommended. These might fix any known bugs in earlier versions.

OCFS2 Cluster File System Setup Guide in Linux

What is OCFS2?
  • OCFS2 is a shared-disk cluster file system for Linux 
  • Capable of providing both high performance and high availability.  
  • Cluster-aware applications can make use of parallel I/O for higher performance with this FS 
  • OCFS2 is mostly used to host Oracle Real application clusters (RAC) database on Linux clusters. 

The below are the high level steps for creating ocfs2 filesystem on top of a multipath'd SAN LUN:

  1. Verify the nodes that will be part of your cluster.
  2. Make sure your LUNs on the SAN end are accessible on all the nodes of the cluster.
  3. If you need multipathing, configure multipath and the multipathing policy based on solution whatever you have.
  4. The following example configuration ( /etc/ocfs2/cluster.conf ) shows you a sample configuration of a 2 node cluster pool. 
  5. If you have heartbeat IP configured on these cluster nodes, use the heartbeat IP for ocfs2 cluster communication and specify the hostname without FQDN. 
  6. Copy the same file to all the hosts in the cluster. 

Sample Config file:
[root@rac-cluster ~]# cat /etc/ocfs2/cluster.conf
node:
        ip_port = 7777
        ip_address = 192.168.1.2
        number = 0
        name = rac-cluster
        cluster = ocfs2
node:
        ip_port = 7777
        ip_address = 192.168.1.3
        number = 1
        name = rac-cluster
        cluster = ocfs2
 
On each node check the status of OCFS2 cluster service and stop "o2cb" if the service is already running. 
# service o2cb status # service o2cb stop
On each node, load the OCFS2 module. 
# service o2cb load
Make the OCFS2 service online on all the nodes. 
# service o2cb online 
Now your OCFS2 cluster is ready.

Format the SAN lun device from any one of the cluster node. 
# mkfs.ocfs2 -b 4k -C 32k -L oraclerac /dev/emcpowera
Where,
-b : Block size
-C : Cluster size
-L : Label

Update /etc/fstab on all the nodes in the cluster with the mount point. 
/dev/emcpowera /u01 ocfs2 _netdev 0 0 
Mount the /u01 

Enable ocfs and o2b service on boot
# chkconfig --level 345 o2cb on# chkconfig --level 345 ocfs2 on 
The /u01 repository setup on a SAN Lun is done.

You can now configure Oracle RAC on this file System.

Configuring Kernel dump in Suse Linux (SLES)


Prerequisites

Kdump stores kernel core dumps under /var. The partition that /var is on must have enough available disk space for the vmcore file, which will be approximately the size of the system's physical memory. By default, the system will attempt to keep 5 vmcore files.

Check the taint status of the kernel (recommended)

Whenever possible, kernel crashes should be reproduced using untainted kernels.

Set up magic SysRq (recommended)

For kernel problems other than a kernel oops or panic, a kernel core dump is not triggered automatically. If the system still responds to keyboard input to some degree, a kernel core dump can be triggered manually through a "magic SysRq" keyboard combination (typically: hold down three keys simultaneously: the left Alt key, the Print Screen / SysRq key and a letter key indicating the command - ' s' for sync, ' c' for core dump), if this feature has been enabled.

For general documentation of the "magic SysRq" feature, please refer to the Documentation/sysrq.txt file in the Linux kernel source.

To enable the magic SysRq feature permanently, edit /etc/sysconfig/sysctl, change the ENABLE_SYSRQ line to ENABLE_SYSRQ="yes". This change becomes active after a reboot. To enable the feature for the running kernel, run
echo 1>/proc/sys/kernel/sysrq


Configure the system for capturing kernel core dumps (SLES 10)
  1. Install the packages kernel-kdump, kdump, and kexec-tools.

    The kernel-kdump package contains a "crash" or "capture" kernel that is started when the primary kernel has crashed and which provides an environment in which the primary kernel's state can be captured. The version of the kernel-dump package needs to be identical to that of the kernel whose state needs to be captured.

    The kexec-tools package contains the tools that make it possible to start the capture kernel from the primary kernel. 
  2. Reserve memory for the capture kernel by passing appropriate parameters to the primary kernel.
    For the x86 and x86_64 architecture use the table below based upon how much memory you have.  
Memory
crashkernel=
0 - 12 GB
64M@16M
13 - 48 GB
128M@16M
49 - 128 GB
256M@16M
129 - 256 GB
512M@16M


For the PPC64 architecture: crashkernel=128M@32M
Note: for Xen installations, this parameter needs to be passed to the GRUB line for the Xen hypervisor, not the module line for the Dom0 kernel.

This can be done as follows: Start YaST, under System, select Boot Loader. On the tab Section Management, select the default section and select Edit. Add the settings to the field labeled Optional Kernel Command Line Parameter , then select Ok and Finish to save the settings.
  1. Activate the kdump system service.

    Run
    chkconfig kdump on

    or in YaST: under System, select System Services (Runlevel), select kdump , then select Enable and Finish.

  1. Reboot the system for the settings to take effect

Test local kernel core dump capture

To test the local kernel core dump capture, follow these steps.
If magic SysRq has been configured:
  1. Magic-SysRq-S to sync (flush out pending writes)
  1. Magic-SysRq-C to trigger the kernel core dump
Alternatively, without magic SysRq:
  1. Open a shell or terminal
  2. Run sync
  1. Run echo c >/proc/sysrq-trigger
Please note that the 'c' must be lower case! Also, the system will not be responsive while the capture is being prepared and made as the capture kernel environment is a limited, non-interactive environment.

Once the system becomes responsive again, verify that a capture file was created as /var/log/dump/ date-time /vmcore.