We are in the process of migrating this forum. A new space will be available soon. We are sorry for the inconvenience.

iSCSI read only


stachox
20-01-2010, 08:54
z tego co ja rozumiem to zwiększa się time out oczekiwania na dostęp do dysku. Jeśli aplikacja zapisuje coś na dysku to pewnie zawiesi sie do czasu uzyskania dostępu do zapisu.

Rysiu
29-08-2009, 19:16
Osobiście zapoznałem się z owymi dodatkami/modyfikacjami...

Może ktoś jednak rozwinąć co one dają? Umożliwiają RPS'owi działanie nawet podczas utraty połączenie z iSCSI... Ale tak dokładniej?

Jeżeli będę miał na RPS'ie uruchomioną jakąś aplikację, która będzie systematycznie zapisywała jakieś szczątkowe informacje na dysku to co się stanie w przypadku utraty łączności z macierzą? Oczywiście zapis nie będzie możliwy ale czy informacje zostaną zmagazynowane w pamięci RAM i zapisane po odzyskaniu dostępu do dysku?

rafmik
11-08-2009, 20:47
Cytat Napisał loozaqq
Mógłby ktoś mi pomóc mam ten sam problem, że dedyk robi się na read only, OVH naprawia mi to, z 20 razy a i tak po kilku godzinach znowu to wystepuje... prosze o odp na gg; 9166666 lub tutaj jeżeli ktoś by był chętny mi pomóc. Dziękuje z góry.
Przeciez masz napisane powyzej co masz zrobic, nixi to dokladnie opisal.

loozaqq
11-08-2009, 19:09
Mógłby ktoś mi pomóc mam ten sam problem, że dedyk robi się na read only, OVH naprawia mi to, z 20 razy a i tak po kilku godzinach znowu to wystepuje... prosze o odp na gg; 9166666 lub tutaj jeżeli ktoś by był chętny mi pomóc. Dziękuje z góry.

loozaqq
06-08-2009, 23:35
mam ten sam problem, tylko że powtórzyło to się z 10 razy Czasami po naprawie usterki OVH potwarzało się od 2 godzin do nawet 15 Wie ktoś może kiedy OVH wyeleminuje ten problem?

rafmik
23-07-2009, 23:17
Wielkie dzięki. Zastosowałem zmiany. Zobaczymy jak się system będzie zachowywał.

Tak na marginesie :
Technik OVH podał mi jako przyczynę awarii : że kernel ma bug zwiazany z kartami Realtec. Co najciekawsze na tym samym kernelu oraz na tej samej karcie serwer działał wiele miesięcy i nagle..... bug się ujawnił (ta....., już w to uwierzyłem).

Jako dodatkowa przyczynę podał przeciażenie mojego RPS'a wysyłajac logi z .... niedzieli w tydzień po awarii kiedy sam próbowałem odtworzyć bład wysyłajac pełno informacji na postfix'a... ręce opadaja normalnie

Jak nie chce mu się nic robić to niech powie ,,nie'' i tyle, bo a) nie musi - wynika to z oferty OVH b) nie ma to sensu. Oferowanie nic nie wartej pomocy robi gorsze wrażenie niż po prostu odmówienie pomocy gdy się ona nie należy (bo akurat tak jest z RPS).

Na koniec po naciskach okazało się, że kiedy miałem awarię jednak był problem z SAN'em z którego korzysta mój RPS (mimo, że na prace.ovh.pl to info się nie pojawiło).

Mimo chęci pomocy ze strony polskiego OVH (i tu duży plus), wyszło tragicznie, bo technik we Francji olal sprawę i tyle. Gdyby nie nixi pewnie bym był w tym samym miejscu co 1,5 tygodnia temu.

nixi
22-07-2009, 17:00
Ale katalog /etc/iscsi wogóle istnieje i zawiera jakieś pliki? W przypadku zmodyfikowanego iscsid (dostarczonego przez OVH - jest on troszkę inny od typowego dystrybucyjnego) bardzo istotny jest plik /etc/iscsi/version Jednak zakładam, że musi u Ciebie istnieć, skoro jak rozumiem proces iscsid jest uruchomiony...

U siebie zmodyfikowałem tylko te 3 podane wcześniej parametry w stosunku do wartości w standardowym pliku konfiguracyjnym. Plik ten możesz znaleźć w źródłach open-iscsi, skoro nie masz go u siebie:
http://www.open-iscsi.org/bits/open-...0-870.3.tar.gz

Przy takiej konfiguracji RPS powinien teoretycznie wytrzymać utratę łączności z serwerem iSCSI wynoszącą do 24h. Nie znaczy, że w tym czasie będzie normalnie działał - utknie zapewne na długim iowait, ale po przywróceniu łączności wszystko powinno wrócić do pierwotnego stanu. Nie miałem okazji sprawdzić w praktyce zachowania przy dłuższych przerwach, ale krótkie zdarzają się od czasu do czasu i ślad po nich można zaobserwować wyłącznie w logach (żadnego przełączenia w tryb read-only) w postaci wpisów, jak poniżej:

Kod:
Jul 16 05:52:37 server iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
Jul 16 05:52:37 server iscsid: connect failed (113)
Jul 16 05:52:37 server last message repeated 10 times
Jul 16 05:52:37 server iscsid: connection1:0 is operational after recovery (12 attempts)

rafmik
22-07-2009, 15:01
Dzieki za wskazówki. Rozumiem, ze jak nie mam wogole /etc/iscsi/iscsid.conf to mam go utworzyc, dodadc wpisy, ktore podales i one po restarcie demona powiny nadpisac wartosci domyslne dla iscsi, dobrze rozumiem? Czy sa to jedyne wpisy, czy cos jeszcze przyadaloby sie dodac aby zmniejszyc prawdpodobienstwo awarii, w sytuacji kiedy komunikacja z NAS zostanie przerwana ?

nixi
19-07-2009, 16:10
Cytat Napisał rafmik
Tym bardziej nie dotykałem kwestii SMART'a.
SMART na RPS-ach to raczej nigdy nie działał...

Cytat Napisał rafmik
Jak rozumiem, działa to tak, że następuje jakiś błąd związany z operacjami dyskowymi (którego nie potrafię w tym momencie nawet zlokalizować w jakiej sytaucji ma miejsce), następnie zgodnie z zawartością fstab następuje podmontowanie w trybie read only. Mogę zmodyfikować fstab żeby error=continue, ale to chyba nie jest najlepsze rozwiązanie problemu, tylko półśrodek.
W przypadku RPS to wszelkie błędy "dyskowe" najczęściej są związane z chwilowymi problemami łączności w sieci. Na optymalnie skonfigurowanym RPS-ie iscsid powinien sobie z nimi poradzić bez przekazywania błędu do wyższej wartswy.

Cytat Napisał rafmik
Jak ktoś ma pomysły co sprawdzać - dajcie znać, bo nie uśmiecha mi się reinstalka serwera
1. Przede wszystkim sprawdzić, czy uruchomiony jest iscsid. Czasem można sobie z tego nie zdawać sprawy, ale bez niego RPS będzie działał całkiem dobrze... do czasu aż nie następi jakikolwiek (nawet bardzo drobny) problem w łączności z serwerem iSCSI.

2. Wspomniana przeze mnie wcześniej konfiguracja tego daemona: /etc/iscsi/iscsid.conf W tym miejscu należy zwrócić uwagę przede wszystkim na 3 istotne parametry, którym warto nadać następujące wartości (rozdział 8.2 dokumentacji open-iscsi):
node.conn[0].timeo.noop_out_interval = 0
node.conn[0].timeo.noop_out_timeout = 0
node.session.timeo.replacement_timeout = 86400

rafmik
16-07-2009, 20:53
Hej,

Wszystko by było fajnie, gdyby nie fakt, że..... nie dokonywałem żadnych zmian i nagle w tym tygodniu zaczęły się kłopoty. A już w szczególności nie dokonywałem ostatnio żadnych zmian związanych z kwestiami dyskowymi. Tym bardziej nie dotykałem kwestii SMART'a.

Nie wiem czy wspomniany błąd był już wcześniej bo od września 2008 pierwszy raz musiałem przeprowadzać testy w trybie rescue. W każdym razie do poniedziałku nic się nie działo.

Jak rozumiem, działa to tak, że następuje jakiś błąd związany z operacjami dyskowymi (którego nie potrafię w tym momencie nawet zlokalizować w jakiej sytaucji ma miejsce), następnie zgodnie z zawartością fstab następuje podmontowanie w trybie read only. Mogę zmodyfikować fstab żeby error=continue, ale to chyba nie jest najlepsze rozwiązanie problemu, tylko półśrodek.

Co gorsza, w tym momencie nie jestem w stanie jednoznacznie stwierdzić czy błąd jest po mojej stronie (choć nie wiem jak bo nie dokonywałem zmian), czy po stronie serwera iSCSI. Jednak za drugim wariantem wskazuje, że na forum OVH w UK znalazłem wątek opisujący identyczny błąd i zachowanie RPS, ale sprawa zakończyła się ... rezygnacją klienta, który poddał się po kilku tygodniach prób uzyskania pomocy od techników OVH.

Jak ktoś ma pomysły co sprawdzać - dajcie znać, bo nie uśmiecha mi się reinstalka serwera

nixi
16-07-2009, 17:45
Cytat Napisał rafmik
Smartctl: Device Read Identity Failed (not an ATA/ATAPI device)
Przecież w tej maszynie nie ma dysku, więc zupełnie nie ma sensu uruchamiać smartctl

Co do meritum sprawy, to proponuję przyjrzeć się zawartości /etc/iscsi/iscsid.conf W tym pliku można parę istotnych rzeczy zoptymalizować.
Polecam lekturę http://www.open-iscsi.org/docs/README zwłaszcza w częściach mówiących, jakie parametry ustawić w przypadku, gdy główna partycja znajduje się na iSCSI.

rafmik
16-07-2009, 15:23
Problem sie powtorzyl. Po testach widze cos takiego :

smartctl version 5.32 Copyright (C) 2002-4 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
Smartctl: Device Read Identity Failed (not an ATA/ATAPI device)
A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.


Czy ktos moze mial doczynienia z takim bledem? Jak to ugryzc, bo im wiecej googlam tym mniej kumam

Update:
Podobno w przypadku RPS, powyższy bład pokazywany w trybie rescue w teście hardware można zignorować.

rafmik
14-07-2009, 16:02
Czy mieliscie kiedys sytuacje, ze ni z tego ni z owego dostep byl tylko jako read only ? Z tego co znalazlem, moze to sie zdarzyc, gdy nie bedzie kontaktu z iSCSI i system ponownie bedzie podmontowywal hd. Tylko, ze na prace.ovh.pl nie ma info, zeby iscsi dla mojego rps mialo ostatnio problemy.

Update:
Wyglada na to, ze info, ze bylo cos ,,nie halo'' z serwerem iSCSI juz sie nie pojawi Co jeszcze bardziej interesujace, zadna z kilku prob uruchomienia serwera w trybie rescue - nie powiodla sie. Caly czas sprawdzalem czy serwer odpowiada na ping'i i ... dostalem maila od ovh, ze serwer ... juz odpowiada podczas, gdy caly czas lecial na ekranie request timeout. Na szczescie po 2 godz, dostalem info, ze interwencja na serwerze zostala zakonczona (o tym, ze wogole bedzie interwencja dowiedzialem sie z infolinii, bo inaczej bym zalozyl ze dla ovh serwer jest ok, skoro zgodnie z otrzymanym mailem podobno mial ,,ping'owac''). Szkoda, ze nikt z technikow sie nawet nie pofatygowal zeby napisac, ze problem byl po stronie ovh. W dodatku problem ten musial sie pojawic dzien wczesniej bo z tego co odnotowalem to juz wczoraj system sie prze'montowal na read only i umoczyl mi czesc uslug

Konkluzja : a) jak nie ma na prace.ovh to wcale nie znaczy, ze nawet jakis czas temu sie cos nie sypnelo b) jak dostajecie maila, ze serwer wlasnie wstal i odpowiada na pingi, to niekoniecznie jest to zgodne z rzeczywistoscia c) nawet jak serwer rzekomo odpowiada i nie spodziewacie sie interwencji technikow to (na szczescie) taka interwencja moze miec miejsce d) nawet jak wtopa nie jest po waszej stronie tylko ovh, to nie liczcie na jakikolwiek message od technikow.
Jedyna rzecz in plus w tej historii, ze od zgloszenia do zakonczenia minelo niewiele czasu - 2h.