кластер Netware и проблемы с dbf файлами

[AlexTorgan]

Есть 2-хузловой кластер. Сервера в нем под управлением Netware 6.5 SP8 с постфиксами для NSS и NCS. В дереве 273 пользователя. В качестве кластерных ресурсов: GroupWise 6.5.7; MySQL, DNS, DHCP и кластерный пул с томами для старых АРМов фокспро 2.6, которые еще у нас используются. Файловая система везде NSS. Client File Caching Enabled = OFF и Level 2 OpLocks Enabled = OFF. Включен режим транзакций на тома с АРМами. Раздел с кластерным пулом находится на внешнем хранилище (HP HSV3000), связь с ним через FC. Началось все с периодических абендов (раз в месяц примерно). Причина - GW. Вначале не обращали внимание - потом стало чаще. После установки на GW сервиспаков проблема с абендами исчезла нопоявилось 2 других:

1) к одному из серверов кластера доступ возможен только по его ДНС имени но не по ДНС имени кластера (со вторым сервером все ок)

2) и самая существенная проблема при выключении сервера:

Содержимое некоторых .dbf файлов (количество записей - 100-500 тысяч, количество работающих с файлами пользователей - не более 10) изменяется следующим образом:
- размер файлов остается неизменным, дата изменения остается неизменной
- в заголовок файла пишется неправильное количество (меньше) записей в таблице
- в конец той записи, которая якобы последняя, пишется маркер конца таблицы.

Foxpro 2.6 при работе с такими таблицами берет количество записей из заголовка файла
и при добавлении новых записей дописывает их не в реальный конец файла, а с некоторым отступом, что приводит к потере данных.
Нарушается содержимое .cdx файлов (индексы), что приводит к некорректной работе АРМов (размер файла не меняется, но, судя по всему, информация в нем соответствует "исправленному" .dbf файлу).

Буду благодарен за любые предложения решения проблемы.

[Андрей Троценко]

...к одному из серверов кластера доступ возможен только по его ДНС имени но не по ДНС имени кластера (со вторым сервером все ок)...

На этом IP всегда будет отзываться ТОЛЬКО активный узел кластера. По определению.

...при выключении сервера:

Содержимое некоторых .dbf файлов (количество записей - 100-500 тысяч, количество работающих с файлами пользователей - не более 10) изменяется следующим образом:
- размер файлов остается неизменным, дата изменения остается неизменной
- в заголовок файла пишется неправильное количество (меньше) записей в таблице
- в конец той записи, которая якобы последняя, пишется маркер конца таблицы.

Foxpro 2.6 при работе с такими таблицами берет количество записей из заголовка файла
и при добавлении новых записей дописывает их не в реальный конец файла, а с некоторым отступом, что приводит к потере данных.
Нарушается содержимое .cdx файлов (индексы), что приводит к некорректной работе АРМов (размер файла не меняется, но, судя по всему, информация в нем соответствует "исправленному" .dbf файлу).

Значит, на момент выключения, кто-либо из клиентов держит открытыми эти файлы. Чудес не бывает - если записи добавлялись, после отключения, в заголовке будет несответствие числа записей реальным. Для ремонта, см. в интернете маленькую утиль, которая корректирует заголовок по физическому размеру файла .dbf, и - переиндексация.
Как простейший вариант уйти от такой проблемы - научите приложение закрывать файлы данных при появлении в директории данных файла-флага, который будет выставляться из скрипта миграции кластера, ну и убираться оттуда же...

[AlexTorgan]

...к одному из серверов кластера доступ возможен только по его ДНС имени но не по ДНС имени кластера (со вторым сервером все ок)...

На этом IP всегда будет отзываться ТОЛЬКО активный узел кластера. По определению.

Я может не совсем толково объяснил что происходит в этом случае. Попытаюсь подробнее: есть 2 сервера SRV1 и SRV2. Их имена в ДНС - srv1.qwerty.asd и srv2.qwerty.asd и есть кластер srv.qwerty.asd. Так вот в момент когда основной сервер srv1 он доступен по ДНС имени srv1.qwerty.asd и srv.qwerty.asd, а вот когда основной сервер srv2 он доступен ТОЛЬКО по имени srv2.qwerty.asd

...при выключении сервера:

Содержимое некоторых .dbf файлов (количество записей - 100-500 тысяч, количество работающих с файлами пользователей - не более 10) изменяется следующим образом:
- размер файлов остается неизменным, дата изменения остается неизменной
- в заголовок файла пишется неправильное количество (меньше) записей в таблице
- в конец той записи, которая якобы последняя, пишется маркер конца таблицы.

Foxpro 2.6 при работе с такими таблицами берет количество записей из заголовка файла
и при добавлении новых записей дописывает их не в реальный конец файла, а с некоторым отступом, что приводит к потере данных.
Нарушается содержимое .cdx файлов (индексы), что приводит к некорректной работе АРМов (размер файла не меняется, но, судя по всему, информация в нем соответствует "исправленному" .dbf файлу).

Значит, на момент выключения, кто-либо из клиентов держит открытыми эти файлы.
[/quote]
Однозначно открытых файлов - нет! Проверялось не единожды.

Чудес не бывает - если записи добавлялись, после отключения, в заголовке будет несответствие числа записей реальным. Для ремонта, см. в интернете маленькую утиль, которая корректирует заголовок по физическому размеру файла .dbf, и - переиндексация.

Это понятно - этим наше сопровождение занимается и исправляет. И сервер не так часто выключается и не так часто это делать нужно. Но! Неприятно это и непонятно

Как простейший вариант уйти от такой проблемы - научите приложение закрывать файлы данных при появлении в директории данных файла-флага, который будет выставляться из скрипта миграции кластера, ну и убираться оттуда же...

Повторюсь - открытых файлов на момент перехода - нет!

[Павел Гарбар]

при переезде кластерного ресурса "IP-address" надо бы на клиентах arp cache передернуть, чтобы DNS-name соответсвовал IP-address, а он - новому MAC-адресу.

[Андрей Троценко]

...в ДНС - srv1.qwerty.asd и srv2.qwerty.asd и есть кластер srv.qwerty.asd. Так вот в момент когда основной сервер srv1 он доступен по ДНС имени srv1.qwerty.asd и srv.qwerty.asd, а вот когда основной сервер srv2 он доступен ТОЛЬКО по имени srv2.qwerty.asd...

Для однозначности, лучше говорить про IP-адреса Не совсем понятно, что значит "доступен".
Для большинства служб, для того, чтобы она стала доступной на какой-либо из нод кластера, достаточно двух строк в скрипте загрузки, аналогичных приведенным для ncp-сервера:
exit_on_error add_secondary_ipaddress $RESOURCE_IP
exit_on_error ncpcon bind --ncpservername=$NCP_SERVER --ipaddress=$RESOURCE_IP

Собственно, первая строчка цепляет IP ресурса ("доступен по DNS-имени" в исходном посте) на активирующуюся ноду. С этого момента ее можно "попинговать" на IP ресурса (srv.qwerty.asd).
Вторая (в общем случае - и прочие) - стартует или привязывает службу на новом адресе. Т.е. все достаточно прозрачно.

...надо бы на клиентах arp cache передернуть, чтобы ... IP-address ... новому MAC-адресу...

А ведь правда !

[AlexTorgan]

...в ДНС - srv1.qwerty.asd и srv2.qwerty.asd и есть кластер srv.qwerty.asd. Так вот в момент когда основной сервер srv1 он доступен по ДНС имени srv1.qwerty.asd и srv.qwerty.asd, а вот когда основной сервер srv2 он доступен ТОЛЬКО по имени srv2.qwerty.asd...

Для однозначности, лучше говорить про IP-адреса Не совсем понятно, что значит "доступен".
Для большинства служб, для того, чтобы она стала доступной на какой-либо из нод кластера, достаточно двух строк в скрипте загрузки, аналогичных приведенным для ncp-сервера:
exit_on_error add_secondary_ipaddress $RESOURCE_IP
exit_on_error ncpcon bind --ncpservername=$NCP_SERVER --ipaddress=$RESOURCE_IP

Собственно, первая строчка цепляет IP ресурса ("доступен по DNS-имени" в исходном посте) на активирующуюся ноду. С этого момента ее можно "попинговать" на IP ресурса (srv.qwerty.asd).
Вторая (в общем случае - и прочие) - стартует или привязывает службу на новом адресе. Т.е. все достаточно прозрачно.

...надо бы на клиентах arp cache передернуть, чтобы ... IP-address ... новому MAC-адресу...

А ведь правда !

С ДНС именами вроде разобрался. Спасибо. А по поводу баз фоксовых ничего не посоветуете?