Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 Oracle RAC и OCFS2 - проблемы  [new]
Gidrobaton
Member

Откуда:
Сообщений: 4
#имеем Oracle RAC кластер и разделямое хранилище, доступное через OCFS2
#
#eth0 - "public" интерфейc и интерфейс для vip
#eth1 - private
#
[root@rac1 ~]# cat /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost

172.16.1.52 rac1
10.255.1.52 rac1-priv

172.16.1.61 rac1-vir
172.16.1.62 rac2-vir

172.16.1.53 rac2
10.255.1.53 rac2-priv

#допустим теряем линк на eth0 первой ноды

[root@rac1 bin]# ifconfig eth0 down

#Заходим через другой интерфейс, запоминаем картину
#eth1:1 поднимается средствами оракла на "неправильном" интерфейсе

[root@rac1 ~]# ifconfig
eth1 Link encap:Ethernet HWaddr 00:30:48:92:DD:83
inet addr:10.255.1.52 Bcast:10.255.1.255 Mask:255.255.255.0
inet6 addr: fe80::230:48ff:fe92:dd83/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:25592 errors:0 dropped:0 overruns:0 frame:0
TX packets:26916 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:7860040 (7.4 MiB) TX bytes:12644085 (12.0 MiB)
Base address:0x6000 Memory:e8300000-e8320000

eth1:1 Link encap:Ethernet HWaddr 00:30:48:92:DD:83
inet addr:172.16.1.61 Bcast:172.16.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Base address:0x6000 Memory:e8300000-e8320000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:26203 errors:0 dropped:0 overruns:0 frame:0
TX packets:26203 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1426393 (1.3 MiB) TX bytes:1426393 (1.3 MiB)


#включаем eth0, и видим на разных физ. интерфейсах IP-интерфейсы из одной сети

[root@rac1 ~]# ifconfig eth0 up
[root@rac1 ~]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:30:48:92:DD:82
inet addr:172.16.1.52 Bcast:172.16.1.255 Mask:255.255.255.0
inet6 addr: fe80::230:48ff:fe92:dd82/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:53607 errors:0 dropped:0 overruns:0 frame:0
TX packets:18470 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4452517 (4.2 MiB) TX bytes:5237990 (4.9 MiB)
Base address:0x5000 Memory:e8000000-e8020000

eth1 Link encap:Ethernet HWaddr 00:30:48:92:DD:83
inet addr:10.255.1.52 Bcast:10.255.1.255 Mask:255.255.255.0
inet6 addr: fe80::230:48ff:fe92:dd83/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:25671 errors:0 dropped:0 overruns:0 frame:0
TX packets:26990 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:7867394 (7.5 MiB) TX bytes:12654207 (12.0 MiB)
Base address:0x6000 Memory:e8300000-e8320000

eth1:1 Link encap:Ethernet HWaddr 00:30:48:92:DD:83
inet addr:172.16.1.61 Bcast:172.16.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Base address:0x6000 Memory:e8300000-e8320000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:26227 errors:0 dropped:0 overruns:0 frame:0
TX packets:26227 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1427131 (1.3 MiB) TX bytes:1427131 (1.3 MiB)


#
#в результатет имеем проблемы типа
#C:\>ping 172.16.1.52
#
#Обмен пакетами с 172.16.1.52 по 32 байт:
#
#Превышен интервал ожидания для запроса.
#Превышен интервал ожидания для запроса.
#Превышен интервал ожидания для запроса.
#
#
#до тех пор пока не сделаешь ручками
#ifconfig eth1:1 del 172.16.1.61
#
#Но это пол-беды
#Вторая нода ребутается по причине указанной в /var/log/messages


Feb 20 15:39:07 rac2 kernel: o2net: no longer connected to node rac1 (num 0) at 172.16.1.52:7777
Feb 20 15:42:29 rac2 kernel: o2net: connected to node rac1 (num 0) at 172.16.1.52:7777
Feb 20 16:46:08 rac2 kernel: o2net: connection to node rac1 (num 0) at 172.16.1.52:7777 has been idle for 30.0 seconds, shutting it down.

1. Как победить перезагрузку в случае потери связи между узлами?
2. Как заставить оракловые сервисы "правильно" конфигурировать vip интерфейсы(у меня они наз-ся vir)?
21 фев 08, 14:23    [5322564]     Ответить | Цитировать Сообщить модератору
 Re: Oracle RAC и OCFS2 - проблемы  [new]
Alex Roudnev
Member

Откуда: Валнут Крик, Калифорния
Сообщений: 5547
1) При чем тут OCFSv2 если у вас запутана конфигурация CRS?
2) Вы включали datavolume (если он у вас поддерживается) на ocfsv2?
3) Запустите для начала еще раз vipca.
4) Телепаты, ау - какя ОС у автора? Ручаюсь что не SLES9 SP3 (на которой все работает из коробки)
а что то вроде RHEL куда вручную воткнули OCFSv2
5) Где у вас OCRFile и CSSFile?

Вообще по уму
- запустите еще раз vipca . Внимательно проверьте там все включая СЕТЕВЫЕ МАСКИ.
- найдите программулину которая делает дамп OCRFile и сделайте его, загляните туда и почитайте, что там система наконфигурила.
- посмотрите логи CRS

Очень все у вас странно. (Хотя эти vip адреса вообще кластеру не слишком нужны, если честно).

Gidrobaton
#имеем Oracle RAC кластер и разделямое хранилище, доступное через OCFS2
#
#eth0 - "public" интерфейc и интерфейс для vip
#eth1 - private
#
[root@rac1 ~]# cat /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost

172.16.1.52 rac1
10.255.1.52 rac1-priv

172.16.1.61 rac1-vir
172.16.1.62 rac2-vir

172.16.1.53 rac2
10.255.1.53 rac2-priv

#допустим теряем линк на eth0 первой ноды

[root@rac1 bin]# ifconfig eth0 down

#Заходим через другой интерфейс, запоминаем картину
#eth1:1 поднимается средствами оракла на "неправильном" интерфейсе

[root@rac1 ~]# ifconfig
eth1 Link encap:Ethernet HWaddr 00:30:48:92:DD:83
inet addr:10.255.1.52 Bcast:10.255.1.255 Mask:255.255.255.0
inet6 addr: fe80::230:48ff:fe92:dd83/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:25592 errors:0 dropped:0 overruns:0 frame:0
TX packets:26916 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:7860040 (7.4 MiB) TX bytes:12644085 (12.0 MiB)
Base address:0x6000 Memory:e8300000-e8320000

eth1:1 Link encap:Ethernet HWaddr 00:30:48:92:DD:83
inet addr:172.16.1.61 Bcast:172.16.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Base address:0x6000 Memory:e8300000-e8320000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:26203 errors:0 dropped:0 overruns:0 frame:0
TX packets:26203 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1426393 (1.3 MiB) TX bytes:1426393 (1.3 MiB)


#включаем eth0, и видим на разных физ. интерфейсах IP-интерфейсы из одной сети

[root@rac1 ~]# ifconfig eth0 up
[root@rac1 ~]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:30:48:92:DD:82
inet addr:172.16.1.52 Bcast:172.16.1.255 Mask:255.255.255.0
inet6 addr: fe80::230:48ff:fe92:dd82/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:53607 errors:0 dropped:0 overruns:0 frame:0
TX packets:18470 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4452517 (4.2 MiB) TX bytes:5237990 (4.9 MiB)
Base address:0x5000 Memory:e8000000-e8020000

eth1 Link encap:Ethernet HWaddr 00:30:48:92:DD:83
inet addr:10.255.1.52 Bcast:10.255.1.255 Mask:255.255.255.0
inet6 addr: fe80::230:48ff:fe92:dd83/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:25671 errors:0 dropped:0 overruns:0 frame:0
TX packets:26990 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:7867394 (7.5 MiB) TX bytes:12654207 (12.0 MiB)
Base address:0x6000 Memory:e8300000-e8320000

eth1:1 Link encap:Ethernet HWaddr 00:30:48:92:DD:83
inet addr:172.16.1.61 Bcast:172.16.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Base address:0x6000 Memory:e8300000-e8320000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:26227 errors:0 dropped:0 overruns:0 frame:0
TX packets:26227 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1427131 (1.3 MiB) TX bytes:1427131 (1.3 MiB)


#
#в результатет имеем проблемы типа
#C:\>ping 172.16.1.52
#
#Обмен пакетами с 172.16.1.52 по 32 байт:
#
#Превышен интервал ожидания для запроса.
#Превышен интервал ожидания для запроса.
#Превышен интервал ожидания для запроса.
#
#
#до тех пор пока не сделаешь ручками
#ifconfig eth1:1 del 172.16.1.61
#
#Но это пол-беды
#Вторая нода ребутается по причине указанной в /var/log/messages


Feb 20 15:39:07 rac2 kernel: o2net: no longer connected to node rac1 (num 0) at 172.16.1.52:7777
Feb 20 15:42:29 rac2 kernel: o2net: connected to node rac1 (num 0) at 172.16.1.52:7777
Feb 20 16:46:08 rac2 kernel: o2net: connection to node rac1 (num 0) at 172.16.1.52:7777 has been idle for 30.0 seconds, shutting it down.

1. Как победить перезагрузку в случае потери связи между узлами?
2. Как заставить оракловые сервисы "правильно" конфигурировать vip интерфейсы(у меня они наз-ся vir)?
21 фев 08, 22:17    [5325599]     Ответить | Цитировать Сообщить модератору
 Re: Oracle RAC и OCFS2 - проблемы  [new]
Alex Roudnev
Member

Откуда: Валнут Крик, Калифорния
Сообщений: 5547
И еще - прежде всего НАПЕЧАТАЙТЕ на бумаге оба /etc/hosts на обоих нодах, положите перед собой и внимательно прочитайте. 50% проблем с крабораком приходит из за неверных имен (DNS или hosts)
21 фев 08, 22:18    [5325603]     Ответить | Цитировать Сообщить модератору
 Re: Oracle RAC и OCFS2 - проблемы  [new]
Alex Roudnev
Member

Откуда: Валнут Крик, Калифорния
Сообщений: 5547
Еще раз внимательно прочел!

А куда вы дели eth0? Почему он у вас стоит в DOWN????

Делать нужно так:
- eth0 и eth1 в ап при старте системы. На каждом - свой адрес.
- после этого запускаете vipca и конфигурите виртуальный адрес.
- он должен прийти на eth0:1 на обоих нодах (на каждой свой)
- если ноду опустить то адрес с нее должен перейти на eth0:2 на другой ноде.

И только так. А у вас все запутано по самые уши!



[root@rac1 ~]# ifconfig
eth1 Link encap:Ethernet HWaddr 00:30:48:92:DD:83
inet addr:10.255.1.52 Bcast:10.255.1.255 Mask:255.255.255.0
inet6 addr: fe80::230:48ff:fe92:dd83/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:25592 errors:0 dropped:0 overruns:0 frame:0
TX packets:26916 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:7860040 (7.4 MiB) TX bytes:12644085 (12.0 MiB)
Base address:0x6000 Memory:e8300000-e8320000

eth1:1 Link encap:Ethernet HWaddr 00:30:48:92:DD:83
inet addr:172.16.1.61 Bcast:172.16.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Base address:0x6000 Memory:e8300000-e8320000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:26203 errors:0 dropped:0 overruns:0 frame:0
TX packets:26203 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1426393 (1.3 MiB) TX bytes:1426393 (1.3
21 фев 08, 22:23    [5325621]     Ответить | Цитировать Сообщить модератору
 Re: Oracle RAC и OCFS2 - проблемы  [new]
Gidrobaton
Member

Откуда:
Сообщений: 4
Alex Roudnev
1) При чем тут OCFSv2 если у вас запутана конфигурация CRS?
2) Вы включали datavolume (если он у вас поддерживается) на ocfsv2?
3) Запустите для начала еще раз vipca.
4) Телепаты, ау - какя ОС у автора? Ручаюсь что не SLES9 SP3 (на которой все работает из коробки)
а что то вроде RHEL куда вручную воткнули OCFSv2
5) Где у вас OCRFile и CSSFile?

Вообще по уму
- запустите еще раз vipca . Внимательно проверьте там все включая СЕТЕВЫЕ МАСКИ.
- найдите программулину которая делает дамп OCRFile и сделайте его, загляните туда и почитайте, что там система наконфигурила.
- посмотрите логи CRS

Очень все у вас странно. (Хотя эти vip адреса вообще кластеру не слишком нужны, если честно).

Gidrobaton
#имеем Oracle RAC кластер и разделямое хранилище, доступное через OCFS2
#
#eth0 - "public" интерфейc и интерфейс для vip
#eth1 - private
#
[root@rac1 ~]# cat /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost

172.16.1.52 rac1
10.255.1.52 rac1-priv

172.16.1.61 rac1-vir
172.16.1.62 rac2-vir

172.16.1.53 rac2
10.255.1.53 rac2-priv

#допустим теряем линк на eth0 первой ноды

[root@rac1 bin]# ifconfig eth0 down

#Заходим через другой интерфейс, запоминаем картину
#eth1:1 поднимается средствами оракла на "неправильном" интерфейсе

[root@rac1 ~]# ifconfig
eth1 Link encap:Ethernet HWaddr 00:30:48:92:DD:83
inet addr:10.255.1.52 Bcast:10.255.1.255 Mask:255.255.255.0
inet6 addr: fe80::230:48ff:fe92:dd83/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:25592 errors:0 dropped:0 overruns:0 frame:0
TX packets:26916 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:7860040 (7.4 MiB) TX bytes:12644085 (12.0 MiB)
Base address:0x6000 Memory:e8300000-e8320000

eth1:1 Link encap:Ethernet HWaddr 00:30:48:92:DD:83
inet addr:172.16.1.61 Bcast:172.16.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Base address:0x6000 Memory:e8300000-e8320000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:26203 errors:0 dropped:0 overruns:0 frame:0
TX packets:26203 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1426393 (1.3 MiB) TX bytes:1426393 (1.3 MiB)


#включаем eth0, и видим на разных физ. интерфейсах IP-интерфейсы из одной сети

[root@rac1 ~]# ifconfig eth0 up
[root@rac1 ~]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:30:48:92:DD:82
inet addr:172.16.1.52 Bcast:172.16.1.255 Mask:255.255.255.0
inet6 addr: fe80::230:48ff:fe92:dd82/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:53607 errors:0 dropped:0 overruns:0 frame:0
TX packets:18470 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4452517 (4.2 MiB) TX bytes:5237990 (4.9 MiB)
Base address:0x5000 Memory:e8000000-e8020000

eth1 Link encap:Ethernet HWaddr 00:30:48:92:DD:83
inet addr:10.255.1.52 Bcast:10.255.1.255 Mask:255.255.255.0
inet6 addr: fe80::230:48ff:fe92:dd83/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:25671 errors:0 dropped:0 overruns:0 frame:0
TX packets:26990 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:7867394 (7.5 MiB) TX bytes:12654207 (12.0 MiB)
Base address:0x6000 Memory:e8300000-e8320000

eth1:1 Link encap:Ethernet HWaddr 00:30:48:92:DD:83
inet addr:172.16.1.61 Bcast:172.16.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Base address:0x6000 Memory:e8300000-e8320000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:26227 errors:0 dropped:0 overruns:0 frame:0
TX packets:26227 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1427131 (1.3 MiB) TX bytes:1427131 (1.3 MiB)


#
#в результатет имеем проблемы типа
#C:\>ping 172.16.1.52
#
#Обмен пакетами с 172.16.1.52 по 32 байт:
#
#Превышен интервал ожидания для запроса.
#Превышен интервал ожидания для запроса.
#Превышен интервал ожидания для запроса.
#
#
#до тех пор пока не сделаешь ручками
#ifconfig eth1:1 del 172.16.1.61
#
#Но это пол-беды
#Вторая нода ребутается по причине указанной в /var/log/messages


Feb 20 15:39:07 rac2 kernel: o2net: no longer connected to node rac1 (num 0) at 172.16.1.52:7777
Feb 20 15:42:29 rac2 kernel: o2net: connected to node rac1 (num 0) at 172.16.1.52:7777
Feb 20 16:46:08 rac2 kernel: o2net: connection to node rac1 (num 0) at 172.16.1.52:7777 has been idle for 30.0 seconds, shutting it down.

1. Как победить перезагрузку в случае потери связи между узлами?
2. Как заставить оракловые сервисы "правильно" конфигурировать vip интерфейсы(у меня они наз-ся vir)?

Две машины под управление RHEL4 и IBM System Storage DS4700, подключенный к этим машинам по Fibre Channel веревкам
Хранилище для них смонтировано в папочку /u03. Тут все нормально - и для первого и для второго узла директория /u03 доступна, файл созданный на одном узле, сразу же появляется на другом, что и требуется при установке. В нормальном режиме все работает и не вызывает претензий.
Насчет vipca тоже все ОК, установка ругалась на то что public интерфейс вовсе не public(частный адрес из 172.16.0.0./12), и, по совету metalink, vipca нам все починила.
Но кластер создавался для того чтобы, при падении одного узла, второй продолжал работать.
Именно на тестах он и начинает капризничать (гасим линк вручную, можно дойти до серверной и вытащить кабель из сетевой карты :) )
я писал:

#допустим теряем линк на eth0 первой ноды

[root@rac1 bin]# ifconfig eth0 down

#Заходим через другой интерфейс, запоминаем картину
#eth1:1 поднимается средствами оракла на "неправильном" интерфейсе


В результате этих манипуляций и всплывают 2 кака$#ки:

1. Второй узел не может достчаться до 7777 порта первого узла и почему то уходит в ребуут

Feb 20 15:39:07 rac2 kernel: o2net: no longer connected to node rac1 (num 0) at 172.16.1.52:7777
Feb 20 15:42:29 rac2 kernel: o2net: connected to node rac1 (num 0) at 172.16.1.52:7777
Feb 20 16:46:08 rac2 kernel: o2net: connection to node rac1 (num 0) at 172.16.1.52:7777 has been idle for 30.0 seconds, shutting it down.

2.Даже после поднятия линка(мы это опять делаем ручками, зайдя на первый узел через второй интерфес со второго узла ) мы не можем достучаться до первого узла по его адресу 172.16.1.52, так как какой-то из кластерных демонов при падении линка eth0, не находя eth0, поднимает виртуальный адрес на eth1, а при поднятии линка на eth0 назад виртуальный адрес не возвращает. В результате мы имеем картину, когда на двух физических интерфейсах адреса из одной сети 172.16.1.0/24 , но пакеты в сеть 172.16.1.0/24 роутятся уже не через eth0 как было до падения линка, а через eth1. Приходится ручками прибивать вторичный IP-интерфейс на eth1, после чего все встает на свои места - демон находит eth0 и поднимает виртуальный адрес уже на нем, как и было в самом начале...
22 фев 08, 02:02    [5325949]     Ответить | Цитировать Сообщить модератору
 Re: Oracle RAC и OCFS2 - проблемы  [new]
Alex Roudnev
Member

Откуда: Валнут Крик, Калифорния
Сообщений: 5547
Кластер вовсе не расчитан на работу при падении одного интерфейса на одном из серверов. Тем более что кластер из 2 узлов принципиально всегда будет ребутить один узел при потере связи между узлами, и ребутить узел с большим номером. Дело в том, что при падении 1 узла из 2 оба теряют кворум. Хотите чтобы не ребутилось - добавляйте третий узел, тогда те узлы, которые останутся связанными, падать не будут. А вообще ораклиный кластер не совсем кластер, если подумать, а большой сопля.

Кластер (тем более криво сделанный оракловый) нормально отрабатывает лишь ПАДЕНИЕ узла. А не падение связи. Более того, так как и ocfsv2 и CRS не понимают больше чем 1 адрес удаленного узла, то весь heartbeat и в том и в другом абсолютно не устойчивы к любым падениям в сетке.

А почему перевызывается узел, ясно вполне - у вас интерконнекшен прописался по видимому через публичные адреса, и при разрыве оного кластер разрывается (а дальше см выше). Мало того, в OCFSv2 два кворума - один через диск другой по сети - а разбираться какой именно потеряли эта дура не умеет.

Я в кластере вообще наплевал на советы Оракла и сделал межсоединение кросс кабелем - это работает еще более менее (ну и загнал туда все эти приватные ИП и OCFSv2 адреса). Так как при соединении через свитчи сделать устойчивую конфигурацию на ораклиных поделках невозможно в принципе (можно наворотить бондинг, добавив тем самым еще кучу неустойчивостей, но надежно это не будет никогда). Хотите - добавьте еще 2 езернета и лепите бондинг как оракл советует, но IMHO это будет еще та сопля.


Gidrobaton
Alex Roudnev
1) При чем тут OCFSv2 если у вас запутана конфигурация CRS?
2) Вы включали datavolume (если он у вас поддерживается) на ocfsv2?
3) Запустите для начала еще раз vipca.
4) Телепаты, ау - какя ОС у автора? Ручаюсь что не SLES9 SP3 (на которой все работает из коробки)
а что то вроде RHEL куда вручную воткнули OCFSv2
5) Где у вас OCRFile и CSSFile?

Вообще по уму
- запустите еще раз vipca . Внимательно проверьте там все включая СЕТЕВЫЕ МАСКИ.
- найдите программулину которая делает дамп OCRFile и сделайте его, загляните туда и почитайте, что там система наконфигурила.
- посмотрите логи CRS

Очень все у вас странно. (Хотя эти vip адреса вообще кластеру не слишком нужны, если честно).

Gidrobaton
#имеем Oracle RAC кластер и разделямое хранилище, доступное через OCFS2
#
#eth0 - "public" интерфейc и интерфейс для vip
#eth1 - private
#
[root@rac1 ~]# cat /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost

172.16.1.52 rac1
10.255.1.52 rac1-priv

172.16.1.61 rac1-vir
172.16.1.62 rac2-vir

172.16.1.53 rac2
10.255.1.53 rac2-priv

#допустим теряем линк на eth0 первой ноды

[root@rac1 bin]# ifconfig eth0 down

#Заходим через другой интерфейс, запоминаем картину
#eth1:1 поднимается средствами оракла на "неправильном" интерфейсе

[root@rac1 ~]# ifconfig
eth1 Link encap:Ethernet HWaddr 00:30:48:92:DD:83
inet addr:10.255.1.52 Bcast:10.255.1.255 Mask:255.255.255.0
inet6 addr: fe80::230:48ff:fe92:dd83/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:25592 errors:0 dropped:0 overruns:0 frame:0
TX packets:26916 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:7860040 (7.4 MiB) TX bytes:12644085 (12.0 MiB)
Base address:0x6000 Memory:e8300000-e8320000

eth1:1 Link encap:Ethernet HWaddr 00:30:48:92:DD:83
inet addr:172.16.1.61 Bcast:172.16.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Base address:0x6000 Memory:e8300000-e8320000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:26203 errors:0 dropped:0 overruns:0 frame:0
TX packets:26203 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1426393 (1.3 MiB) TX bytes:1426393 (1.3 MiB)


#включаем eth0, и видим на разных физ. интерфейсах IP-интерфейсы из одной сети

[root@rac1 ~]# ifconfig eth0 up
[root@rac1 ~]# ifconfig
eth0 Link encap:Ethernet HWaddr 00:30:48:92:DD:82
inet addr:172.16.1.52 Bcast:172.16.1.255 Mask:255.255.255.0
inet6 addr: fe80::230:48ff:fe92:dd82/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:53607 errors:0 dropped:0 overruns:0 frame:0
TX packets:18470 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4452517 (4.2 MiB) TX bytes:5237990 (4.9 MiB)
Base address:0x5000 Memory:e8000000-e8020000

eth1 Link encap:Ethernet HWaddr 00:30:48:92:DD:83
inet addr:10.255.1.52 Bcast:10.255.1.255 Mask:255.255.255.0
inet6 addr: fe80::230:48ff:fe92:dd83/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:25671 errors:0 dropped:0 overruns:0 frame:0
TX packets:26990 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:7867394 (7.5 MiB) TX bytes:12654207 (12.0 MiB)
Base address:0x6000 Memory:e8300000-e8320000

eth1:1 Link encap:Ethernet HWaddr 00:30:48:92:DD:83
inet addr:172.16.1.61 Bcast:172.16.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Base address:0x6000 Memory:e8300000-e8320000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:26227 errors:0 dropped:0 overruns:0 frame:0
TX packets:26227 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1427131 (1.3 MiB) TX bytes:1427131 (1.3 MiB)


#
#в результатет имеем проблемы типа
#C:\>ping 172.16.1.52
#
#Обмен пакетами с 172.16.1.52 по 32 байт:
#
#Превышен интервал ожидания для запроса.
#Превышен интервал ожидания для запроса.
#Превышен интервал ожидания для запроса.
#
#
#до тех пор пока не сделаешь ручками
#ifconfig eth1:1 del 172.16.1.61
#
#Но это пол-беды
#Вторая нода ребутается по причине указанной в /var/log/messages


Feb 20 15:39:07 rac2 kernel: o2net: no longer connected to node rac1 (num 0) at 172.16.1.52:7777
Feb 20 15:42:29 rac2 kernel: o2net: connected to node rac1 (num 0) at 172.16.1.52:7777
Feb 20 16:46:08 rac2 kernel: o2net: connection to node rac1 (num 0) at 172.16.1.52:7777 has been idle for 30.0 seconds, shutting it down.

1. Как победить перезагрузку в случае потери связи между узлами?
2. Как заставить оракловые сервисы "правильно" конфигурировать vip интерфейсы(у меня они наз-ся vir)?

Две машины под управление RHEL4 и IBM System Storage DS4700, подключенный к этим машинам по Fibre Channel веревкам
Хранилище для них смонтировано в папочку /u03. Тут все нормально - и для первого и для второго узла директория /u03 доступна, файл созданный на одном узле, сразу же появляется на другом, что и требуется при установке. В нормальном режиме все работает и не вызывает претензий.
Насчет vipca тоже все ОК, установка ругалась на то что public интерфейс вовсе не public(частный адрес из 172.16.0.0./12), и, по совету metalink, vipca нам все починила.
Но кластер создавался для того чтобы, при падении одного узла, второй продолжал работать.
Именно на тестах он и начинает капризничать (гасим линк вручную, можно дойти до серверной и вытащить кабель из сетевой карты :) )
я писал:

#допустим теряем линк на eth0 первой ноды

[root@rac1 bin]# ifconfig eth0 down

#Заходим через другой интерфейс, запоминаем картину
#eth1:1 поднимается средствами оракла на "неправильном" интерфейсе


В результате этих манипуляций и всплывают 2 кака$#ки:

1. Второй узел не может достчаться до 7777 порта первого узла и почему то уходит в ребуут

Feb 20 15:39:07 rac2 kernel: o2net: no longer connected to node rac1 (num 0) at 172.16.1.52:7777
Feb 20 15:42:29 rac2 kernel: o2net: connected to node rac1 (num 0) at 172.16.1.52:7777
Feb 20 16:46:08 rac2 kernel: o2net: connection to node rac1 (num 0) at 172.16.1.52:7777 has been idle for 30.0 seconds, shutting it down.

2.Даже после поднятия линка(мы это опять делаем ручками, зайдя на первый узел через второй интерфес со второго узла ) мы не можем достучаться до первого узла по его адресу 172.16.1.52, так как какой-то из кластерных демонов при падении линка eth0, не находя eth0, поднимает виртуальный адрес на eth1, а при поднятии линка на eth0 назад виртуальный адрес не возвращает. В результате мы имеем картину, когда на двух физических интерфейсах адреса из одной сети 172.16.1.0/24 , но пакеты в сеть 172.16.1.0/24 роутятся уже не через eth0 как было до падения линка, а через eth1. Приходится ручками прибивать вторичный IP-интерфейс на eth1, после чего все встает на свои места - демон находит eth0 и поднимает виртуальный адрес уже на нем, как и было в самом начале...
22 фев 08, 02:52    [5325963]     Ответить | Цитировать Сообщить модератору
 Re: Oracle RAC и OCFS2 - проблемы  [new]
Alex Roudnev
Member

Откуда: Валнут Крик, Калифорния
Сообщений: 5547
И еще поясните - что за советы металинка по которым vipca все починила?? Сколько ставил - просто шел дальше без всяких советов (мало ли что vipca думает про себя). Вы там не намудрили с масками или сетями???

Но в принципе понятно
- у вас связь узлов настроена (то ли в crs то ли в ocfs) через паблик интерфейс
- вы убиваете один из паблик интерфейсов
- узлы теряют связь
- так как их всего два, то ОБА теряют КВОРУМ
- так как оба теряют кворум, то они не могут решить кто главный иначе, чем _главный тот у кого нумер меньше_. Тот кто не главный падает чтобы не мешать. Тот кто главный зачем то (видимо, глюк) перетаскивает vip на приватный езернет и работает дальше (то что у него интерфейс упал - он игнорирует, так как с точки зрения кластера, связь упала у обоих).

Вам еще везет что OCFS и CRS как то посчитали главным ОДИН и тот же узел. Могли посчитать и разные - и перевызвать ОБА.
22 фев 08, 03:10    [5325968]     Ответить | Цитировать Сообщить модератору
 Re: Oracle RAC и OCFS2 - проблемы  [new]
denix1
Member

Откуда: Киев
Сообщений: 4656
неплохо бы еще указать версию софта
в частности CRS
рекомендуется 10.2.0.3 с последним доступным бандлом поверх него
там как раз и правились некоторые вещи связанные с тем что CSSD по какой-то причине
выбирает паблик сетку для межузлового общения, вместо приватной

ПС.
тот факт что у Вас виртуальный АйПи поднимается на приватном интерфейса
говорит о граблях в конфигурации оного - потому как такого точно никогда не наблюдал...
Вы случаем при создании не пречислили для VIPa все интерфейсы на узле ? :)

ПС2. как Алекс уже писал нужно очень аккуратно выставлять маски сети при создании VIP,
потому как потом можно потратить уйму времени на трейс появляющихся граблей,
хотя у Вас 3 раза по 255 - трудно ошибиться

ПС3. тех.поддержка Оракла что-то уже ответила по данной проблеме ?
22 фев 08, 16:13    [5329521]     Ответить | Цитировать Сообщить модератору
 Re: Oracle RAC и OCFS2 - проблемы  [new]
Gidrobaton
Member

Откуда:
Сообщений: 4
denix1
неплохо бы еще указать версию софта
в частности CRS
рекомендуется 10.2.0.3 с последним доступным бандлом поверх него
там как раз и правились некоторые вещи связанные с тем что CSSD по какой-то причине
выбирает паблик сетку для межузлового общения, вместо приватной

Софт 10.2.0.1
Пока не пробывал обновлять всю эту кашу до 10.2.0.3 - займусь этим после праздников
Похожая проблема наблюдалась у
http://oss.oracle.com/pipermail/ocfs2-users/2006-August/000676.html , где Alex Roudnev тоже учавствовал в дискуссии, но это было довольно давно...

denix1

ПС.
тот факт что у Вас виртуальный АйПи поднимается на приватном интерфейса
говорит о граблях в конфигурации оного - потому как такого точно никогда не наблюдал...
Вы случаем при создании не пречислили для VIPa все интерфейсы на узле ? :)


Нет, там все норм
eth0 для "паблик" интерфейса и для виртуальных адресов(хоть и адреса из диапазона частных 172.16.0.0/12) - интерфейсы из сети 172.16.1.0/24
eth1 для приват - соединяет напрямую 2 машины без промежуточного активного оборудования кроссовером - интерфейсы из сети 10.255.1.0/24

denix1

ПС2. как Алекс уже писал нужно очень аккуратно выставлять маски сети при создании VIP,
потому как потом можно потратить уйму времени на трейс появляющихся граблей,
хотя у Вас 3 раза по 255 - трудно ошибиться

На самом деле сложно ошибиться - я с масками на "ты" :)
denix1

ПС3. тех.поддержка Оракла что-то уже ответила по данной проблеме ?

Пока не писал - накачу все обновления - там будет видно...
22 фев 08, 18:08    [5330068]     Ответить | Цитировать Сообщить модератору
 Re: Oracle RAC и OCFS2 - проблемы  [new]
Gidrobaton
Member

Откуда:
Сообщений: 4
Alex Roudnev
И еще поясните - что за советы металинка по которым vipca все починила?? Сколько ставил - просто шел дальше без всяких советов (мало ли что vipca думает про себя). Вы там не намудрили с масками или сетями???

Но в принципе понятно
- у вас связь узлов настроена (то ли в crs то ли в ocfs) через паблик интерфейс
- вы убиваете один из паблик интерфейсов
- узлы теряют связь
- так как их всего два, то ОБА теряют КВОРУМ
- так как оба теряют кворум, то они не могут решить кто главный иначе, чем _главный тот у кого нумер меньше_. Тот кто не главный падает чтобы не мешать. Тот кто главный зачем то (видимо, глюк) перетаскивает vip на приватный езернет и работает дальше (то что у него интерфейс упал - он игнорирует, так как с точки зрения кластера, связь упала у обоих).

Вам еще везет что OCFS и CRS как то посчитали главным ОДИН и тот же узел. Могли посчитать и разные - и перевызвать ОБА.


Во время установки инсталлятору не понравилось что паблик адреса - из диапазона частных (rfc 1918)
Номер и ошибки и вывел на металинк, который посоветовал просто запустить vipca, которая все и сконфигурировала как надо.

А то что ребутать узел когда теряется связь - нормальное дело - для меня является открытием.
22 фев 08, 18:15    [5330098]     Ответить | Цитировать Сообщить модератору
 Re: Oracle RAC и OCFS2 - проблемы  [new]
Alex Roudnev
Member

Откуда: Валнут Крик, Калифорния
Сообщений: 5547
denix1
неплохо бы еще указать версию софта
в частности CRS
рекомендуется 10.2.0.3 с последним доступным бандлом поверх него
там как раз и правились некоторые вещи связанные с тем что CSSD по какой-то причине
выбирает паблик сетку для межузлового общения, вместо приватной

ПС.
тот факт что у Вас виртуальный АйПи поднимается на приватном интерфейса
говорит о граблях в конфигурации оного - потому как такого точно никогда не наблюдал...
Вы случаем при создании не пречислили для VIPa все интерфейсы на узле ? :)

ПС2. как Алекс уже писал нужно очень аккуратно выставлять маски сети при создании VIP,
потому как потом можно потратить уйму времени на трейс появляющихся граблей,
хотя у Вас 3 раза по 255 - трудно ошибиться

ПС3. тех.поддержка Оракла что-то уже ответила по данной проблеме ?


Он у него поднимается там после того, как автор РУКАМИ кладет паблик интерфейс. CRS на это не расчитан абсолютно.

нужно
- обязательно обновить до 10.2.0.3, 10.2.0.1 с кластером юзать НЕЛЬЗЯ. (Если i386 то вообще категорически нельзя)
- тестировать не удавливанием интерфейса в даун, а хотя бы выдергиванием интерфейса или укладыванием его на свитче
- понимать что если упадет интерфейс на узле1, то кластер развалится - перевызовет узел 2 как менее приоритетный и будет пытаться поднять сервисы на узле1, у которого не стало интерфейса. Если кластер нужен для НАДЕЖНОСТИ то ставьте третий узел (я не виноват что Оракл не сделал ни мультиинтерфейсного соединения, ни монтиторинга гейтвея, как сделано в любом нормальном кластере).
- если нужна надежность из 2 узлов, то все что можно придумать - это бондинг или прямое межсоединение (оракл его не любит но оно работает). И все равно будет падать вместе с ненулевой вероятностью пока не добавится третий узел.

Вообще ораклиные кластеры бесперебойной работы обеспечить не способны. RAC - потому что там обшие диски и сам кластер сделан криво, а DataGuard потому что там обзервер и файлова достаточно плохо сделаны и ненадежны (хотя при ручном управлении, к примеру, последний может обеспечить абсолютную надежность, в отличие от краборака). Краборак обеспечивает защиту от мелких сбоев и обеспечивает масштабирование пефоменса, а не защиту от фатальных сбоев.
23 фев 08, 03:30    [5330765]     Ответить | Цитировать Сообщить модератору
 Re: Oracle RAC и OCFS2 - проблемы  [new]
Ааз
Member

Откуда: Москва/Протвино
Сообщений: 4274
Alex Roudnev
Вообще ораклиные кластеры бесперебойной работы обеспечить не способны. RAC - потому что там обшие диски и сам кластер сделан криво, а DataGuard потому что там обзервер и файлова достаточно плохо сделаны и ненадежны (хотя при ручном управлении, к примеру, последний может обеспечить абсолютную надежность, в отличие от краборака). Краборак обеспечивает защиту от мелких сбоев и обеспечивает масштабирование пефоменса, а не защиту от фатальных сбоев.
Леша, ну не отпугивай клиентов так уж жёстко :-).

Про бесперебойность (fault tolerance) - это маркетроиды додумали и через "белые бумаги" (white papers) и прочие их маркетроидные штучки внедрили в сознание потенциальных заказчиков. В технологии такой фичи не предусмотрено, ясень пень. HA (High Availability) говорит только о том, что сервис не будет полностью недоступен. Т.е. новые клиенты не будут посланы в ... степь... типо. А что касается сеансов, работавший со сбойнувшим экземпляром - на усмотрение разработчика. МеханизЬмы оповещения есть, возможность обработки exception'ов есть... (TAF, FAN, etc) ну и... всё.

Сам clusterware тоже ещё тот. И ты его слабости показал неоднократно. Есть такая "феня". В пользовательском режиме (без внедрения в ядро ОС) самые корневые процессы не могут гарантировать надёжность кластерности (убыл, прибыл, сдох, ...).

DataGuard - если его понимать в том смысле, что это backup, готовый к (автоматическому и т.п.) применению поступающих новых архивных журналов или redo блоков прямо в on-line, то эта "падла" неубойна. Обвязка вокруг неё (в т.ч. через полюбившийся тебе OEM или в командной строке - dgrmgrl - суть DataGuard Broker) может глючить. Дык! И ты прав - для новичка через OEM проще не лажануццо.

Собсно... я не поспорить, а уточнить :-)

Всего
23 фев 08, 06:45    [5330787]     Ответить | Цитировать Сообщить модератору
 Re: Oracle RAC и OCFS2 - проблемы  [new]
denix1
Member

Откуда: Киев
Сообщений: 4656
Alex Roudnev
...
Он у него поднимается там после того, как автор РУКАМИ кладет паблик интерфейс. CRS на это не расчитан абсолютно.

только с 10.2.0.3 Oracle отписал что не стоит тестировать сбой интерфейса путем ifconfig down,
а и то для Linux это оставлено как дозволенный(не знаю насколько поддерживаемый) вариант
23 фев 08, 12:45    [5330923]     Ответить | Цитировать Сообщить модератору
 Re: Oracle RAC и OCFS2 - проблемы  [new]
Alex Roudnev
Member

Откуда: Валнут Крик, Калифорния
Сообщений: 5547
Ну а что я могу сделать.

Есть аксиомные вещи в кластерах
- нужен мониторинг доступа. То есть я должен иметь возможность указатьь узлу, что _проверяй доступ на такой то адрес, и если он пропал - то считай что ты потерял связь_;
- нужно множество heartbeat соединений, хотя бы 2 - 3 на узел. Для того, чтобы кластер мог
различать падение одного свитча или интерфейса на свитче и падение узла.
- нужен внешний fencing.

Ничего этого у оракла нету ни в RAC/ASM ни в OCFSv2 (но есть к примеру и у Veritas и в Linux heartbeat). У OCFSv2 к тому же есть еще одно свойство - даже если файловая система ничего не делает и давно уже не делала, все равно падение связи вызовет перевызов узла вместо попыток просто перемонтировать ФС с нуля. В итоге простое монтирование ФС для бэкапов через OCFS сразу вносит офигенную неустойчивость в систему. Все попытки это объяснить тамошним индусам (что нужно все таки выделять состояние ФС - ничего не делаем - и в этом случае обрабатывать падения кворума иначе, без перевызова узла) привели лишь к обидам.

PS. Про DG я написал - само оно замечательно неубойно. А вот обвязка дохнет легко и просто. То есть шансов, что она вам базу сама переключит в случае сбоя, без участия человека - примерно 50/50.


Ааз
Alex Roudnev
Вообще ораклиные кластеры бесперебойной работы обеспечить не способны. RAC - потому что там обшие диски и сам кластер сделан криво, а DataGuard потому что там обзервер и файлова достаточно плохо сделаны и ненадежны (хотя при ручном управлении, к примеру, последний может обеспечить абсолютную надежность, в отличие от краборака). Краборак обеспечивает защиту от мелких сбоев и обеспечивает масштабирование пефоменса, а не защиту от фатальных сбоев.
Леша, ну не отпугивай клиентов так уж жёстко :-).

Про бесперебойность (fault tolerance) - это маркетроиды додумали и через "белые бумаги" (white papers) и прочие их маркетроидные штучки внедрили в сознание потенциальных заказчиков. В технологии такой фичи не предусмотрено, ясень пень. HA (High Availability) говорит только о том, что сервис не будет полностью недоступен. Т.е. новые клиенты не будут посланы в ... степь... типо. А что касается сеансов, работавший со сбойнувшим экземпляром - на усмотрение разработчика. МеханизЬмы оповещения есть, возможность обработки exception'ов есть... (TAF, FAN, etc) ну и... всё.

Сам clusterware тоже ещё тот. И ты его слабости показал неоднократно. Есть такая "феня". В пользовательском режиме (без внедрения в ядро ОС) самые корневые процессы не могут гарантировать надёжность кластерности (убыл, прибыл, сдох, ...).

DataGuard - если его понимать в том смысле, что это backup, готовый к (автоматическому и т.п.) применению поступающих новых архивных журналов или redo блоков прямо в on-line, то эта "падла" неубойна. Обвязка вокруг неё (в т.ч. через полюбившийся тебе OEM или в командной строке - dgrmgrl - суть DataGuard Broker) может глючить. Дык! И ты прав - для новичка через OEM проще не лажануццо.

Собсно... я не поспорить, а уточнить :-)

Всего
25 фев 08, 22:17    [5335594]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить