Za mało miejsca na dysku „/” w instancji AWS


28

Używam instancji Ubuntu 11.04 dla mojego serwera WWW w chmurze AWS, teraz dostaję brak miejsca na dysku / partycji mojego serwera. df - powiedz to

Filesystem            Size  Used Avail Use% Mounted on
/dev/xvda1            7.9G  7.8G   97M  99% /
proc                     0     0     0   -  /proc
none                     0     0     0   -  /sys
fusectl                  0     0     0   -  /sys/fs/fuse/connections
none                     0     0     0   -  /sys/kernel/debug
none                     0     0     0   -  /sys/kernel/security
none                  3.7G  112K  3.7G   1% /dev
none                     0     0     0   -  /dev/pts
none                  3.7G     0  3.7G   0% /dev/shm
none                  3.7G   80K  3.7G   1% /var/run
none                  3.7G     0  3.7G   0% /var/lock
/dev/xvdb             414G   16G  377G   4% /mnt

Teraz próbowałem te rzeczy dla uzyskania pewnego dodatkowego miejsca na / partycji

  • Wyczyść wszystkie pliki dziennika dla Apache.
  • Usunięto wszystkie niepotrzebne pliki z serwera.
  • Oczyszczanie katalogu domowego.

Ale wciąż nie mam wystarczająco dużo miejsca. Ten typ wystąpienia to m1.large z 8 GB EBS. Teraz mam dość miejsca na dysku w / dev / xvdb .

Czy istnieje sposób na przydzielenie miejsca na dysku do / z / dev / xvdb lub Dowolnych innych sposobów. Proszę zasugerować mi możliwe rozwiązanie tego problemu. Czy można użyć tej samej partycji / dev / xvdb z inną instancją.


1
Aktualizacja 2017: Amazon umożliwia obecnie zmianę rozmiaru dysków (nawet dysku rozruchowego) w locie! zobacz moją SO odpowiedź tutaj: stackoverflow.com/a/42791031/7022062
Dmitry Shevkoplyas

Odpowiedzi:


26

Odpowiedź jest dwojaka.

Obejście: użyj / dev / xvdb (/ mnt) dla danych tymczasowych

Jest to tak zwane efemeryczne przechowywanie Twojego wystąpienia Amazon EC2, a jego cechy są znacznie różne niż w przypadku trwałego magazynu Amazon EBS używanego gdzie indziej. W szczególności ta efemeryczna pamięć masowa zostanie utracona w cyklach stop / start i może zasadniczo zniknąć , więc zdecydowanie nie chcesz umieszczać w niej niczego o trwałej wartości, tj. Umieszczać tam tylko dane tymczasowe, na które możesz sobie pozwolić łatwo stracić lub odbudować , jak plik wymiany lub ściśle tymczasowe dane używane podczas obliczeń. Oczywiście możesz przechowywać na przykład ogromne indeksy, ale musisz być przygotowany na ich odbudowę po wyczyszczeniu pamięci z jakiegokolwiek powodu (ponowne uruchomienie instancji, awaria sprzętu, ...).

Rozwiązanie: zmień rozmiar / dev / xvda1 (/), aby uzyskać pożądaną pamięć

Jest to tak zwane urządzenia głównego bagażu Twojego Amazon EBS-backed instancji EC2, co ułatwia Amazon EBS na elastyczność i trwałość w szczególności, czyli dane umieścić tam jest dość bezpieczna i przetrwa instancji awarie; możesz jeszcze bardziej zwiększyć elastyczność i trwałość, wykonując regularne migawki woluminu EBS, które są przechowywane na Amazon S3 , o znanej trwałości 99,999999999%.

Ta funkcja migawki umożliwia z kolei rozwiązanie problemu, o ile możesz zastąpić bieżącą pamięć root 8 GB EBS (/ dev / xvda1) jedną większą lub mniejszą wielkością, jak chcesz. Proces został opisany w doskonałym artykule Erica Hammonda Zmiana rozmiaru dysku głównego w działającej instancji rozruchowej EBS Boot EC2 :

Tak długo, jak jesteś w porządku z krótkim czasem przestoju na instancji EC2 (kilka minut), możesz zmienić główny wolumin EBS na większą kopię, bez potrzeby uruchamiania nowej instancji.

Jeśli odpowiednio przygotujesz kroki, które opisuje (bardzo polecam przetestowanie ich za pomocą instancji EC2, aby zapoznać się z procedurą lub zautomatyzować ją nawet za pomocą skryptu dostosowanego), powinieneś być w stanie zakończyć proces kilkoma rzeczywiście tylko kilka minut przestoju.

Większość opisanych kroków można również wykonać za pomocą konsoli zarządzania AWS , co pozwala uniknąć obsługi narzędzi API Amazon EC2 ; sprowadza się to do:

  • zatrzymaj (nie zakończ!) instancję EC2
  • odłącz wolumin EBS od zatrzymanej instancji
  • utwórz migawkę odłączonego woluminu EBS
  • utwórz nowy (większy) wolumin EBS z utworzonej migawki
  • dołącz nowy wolumin EBS do instancji EC2 ( Ważne ! Jeśli jest to twoje urządzenie root, pamiętaj, aby nazwać je dokładnie jako urządzenie root instancji, jak wspomniano, np. (/ dev / sda1) lub (/ dev / xdva1) w przeciwnym razie zostanie podłączone jako urządzenie blokowe, a nie jako urządzenie root, i nie będzie można uruchomić instancji, ponieważ dla instancji nie będzie wymienionego urządzenia root.)
  • SSH do działającej instancji i za pomocą potwierdź, że wszystko jest w porządku df -ah
    • w przypadku, gdy system nie jest automatycznie zmniejszane do systemu plików, trzeba to zrobić ręcznie, jak wyjaśniono w artykule Erica

Powodzenia!


Alternatywny

Ze względu na uniwersalność i łatwość korzystania z tych woluminów EBS, dodatkową opcją byłoby dołączyć więcej woluminów EBS do instancji i przenieść wyraźnie rozłączne obszary zainteresowania tam.

Na przykład, używamy parę ładnych ciężkich aplikacji Java, każdy zużywa 1-2GB dyskowej na wersji; aby ułatwić aktualizację wersji i ogólnie móc przenosić te aplikacje do różnych instancji według własnego uznania, umieściłem je na dedykowanych woluminach EBS, montując je do instancji i miękko łącząc je z pożądaną lokalizacją, np. zwykle /var/lib/<app>/<version>i /usr/local/<app>/<version>.

Dzięki tej metodzie, obecnie działa EC2 instancji z pamięci urządzenia korzeń nadal w domyślnym rozmiarze 8GB (podobnie jak Twoja), ale czasami nawet do 8 woluminów EBS o różnych rozmiarach (1-15GB) dołączone także.

Trzeba zdawać sobie sprawę z potencjalnych problemów z wydajnością sieci, choć, o ile wszystkie te tomy EBS używasz bardzo samej sieci LAN za I / O, które mogłyby uzyskując odpowiednie wzrost wydajności nawet, czy nasycić swoją sieć w skrajnych przypadkach - tak jak zwykle to zależy na temat zastosowania i dostępnego obciążenia.


Korzystam z / dev / xvdb, aby utrzymać moją bazę danych, która ma teraz rozmiar prawie 16 GB. Jeden proces w tle działa, aby zachować aktualność. Więc co powinno być najlepszym trwałym miejscem do przechowywania tej bazy danych. Czy powinienem wybrać Amazon RDS lub Amazon DynamoDB. jaka jest twoja sugestia. korzystam z serwera PHP w tej instancji.
Sumant

2
@Sumant: To nie jest dobre, więc zrobiłeś dokładnie to, co niebezpieczne, mianowicie umieszczając dane, które mają zostać utrwalone na dysku, który może zasadniczo zniknąć w dowolnym momencie (zazwyczaj tak nie jest, należy tak traktować)? Mam nadzieję, że nie ma pszczoła mylące w tym zakresie - należy być bardzo ostrożnym przy łagodzeniu to w celu utraty danych unikaj podczas procesu (Ci zrobić mieć kopie zapasowe baz danych niezależnie od tego, prawda?)!
Steffen Opel

@Sumant: Jeśli chodzi o twoje pytanie - nie musisz wcale zmieniać architektury aplikacji (lub DB), aby rozwiązać problem z pamięcią masową, po prostu zmień rozmiar dysku głównego lub dołącz więcej woluminów EBS, zgodnie z sugestią. Jeśli jednak chcesz poprawić i oddzielić również warstwę DB, co jest zasadniczo dobrą rzeczą z myślą o przyszłym wzroście (ale wiąże się z odpowiednimi kosztami od samego początku) i zakładając, że obecnie korzystasz z MySQL, to Amazon RDS byłby idealnym i wygodnym wyborem. Amazon DynamoDB wymaga całkowicie nowej architektury aplikacji i dotyczy tylko określonych przypadków użycia.
Steffen Opel

1
@Sumant: Należy jednak pamiętać, że migracja bazy danych do instancji RDS m1.small może w rzeczywistości wykazywać wolniejszą wydajność niż bieżąca wersja MySQL na EC2, na której działa m1.large z odpowiednimi korzyściami dla wydajności procesora i operacji we / wy - niezależnie od tego, czy ma to zastosowanie, zależy jednak od bieżącego obciążenia bazy danych. Oczywiście możesz również użyć większych instancji RDS, aby temu zaradzić, ale Twój koszt odpowiednio wzrośnie.
Steffen Opel

1

Tak, to prosty sposób, aby go fstab, a następnie zamontować, aby powiedzieć / var / www / html / files2 /

następnie mkdir / var / www / html / files2 / website następnie ln -s -d / var / www / html / website / var / www / html / files2 / website


użyj UUID do zamontowania partycji za pomocą polecenia blkids i fdisk powiedz „/ dev / vxds /”, aby utworzyć partycję. Użyj programu Midnight Commander, aby przenieść pliki z F6 z jednego folderu do drugiego, upewnij się, że wybierasz właściwy folder pod pozycją montowania oh i oczywiście będziesz musiał zamontować -a po dodaniu do fstab
Daniel Chay

0

Dzisiaj napotkałem ten sam problem, gdy przestajesz używać nowej intencji ec2, domyślnie EBS ma 8 GB. Możesz zmienić rozmiar dołączonego EBS bez tworzenia nowego miejsca lub wykonywania migawki lub odłączania EBS. Oto trzy kroki, które możesz wykonać:

  1. Zmień rozmiar woluminu EBS
  2. Zmień rozmiar partycji
  3. Zmień rozmiar partycji W pierwszym kroku przejdź do konsoli AWS i kliknij EBS, zmień żądany rozmiar i kliknij modyfikuj.

W przypadku pozostałych kroków postępuj zgodnie z tym artykułem, jeśli masz pytania, które możesz zadać.

Dzięki!

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.