AWS ElasticBeanstalk dokująca-cienka pula się zapełnia i powoduje ponowne zamontowanie systemu plików jako tylko do odczytu?

Nie mogę zrozumieć, w jaki sposób AWS konfiguruje swoją „cienką pulę” Dockera na ElasticBeanstalk i jak się zapełnia. Moja cienka pula dokerów w jakiś sposób się zapełnia i powoduje awarię aplikacji podczas próby zapisu na dysk.

To jest z wnętrza kontenera:

>df -h
>     /dev/xvda1                  25G  1.4G   24G   6%

W rzeczywistości EBS ma przydzielony dysk o pojemności 25 GB; du -sh /Zwraca 1,6 GB .

Na zewnątrz w EC2 zaczyna się wystarczająco niewinnie ... (via lvs)

LV          VG     Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
docker-pool docker twi-aot--- 11.86g             37.50  14.65

Jednak system plików wkrótce zostanie ponownie zamontowany jako tylko do odczytu. przez dmesg:

[2077620.433382] Buffer I/O error on device dm-4, logical block 2501385
[2077620.437372] EXT4-fs warning (device dm-4): ext4_end_bio:329: I/O error -28 writing to inode 4988708 (offset 0 size 8388608 starting block 2501632)
[2077620.444394] EXT4-fs warning (device dm-4): ext4_end_bio:329: I/O error     [2077620.473581] EXT4-fs warning (device dm-4): ext4_end_bio:329: I/O error -28 writing to inode 4988708 (offset 8388608 size 5840896 starting block 2502912)

[2077623.814437] Aborting journal on device dm-4-8.
[2077649.052965] EXT4-fs error (device dm-4): ext4_journal_check_start:56: Detected aborted journal
[2077649.058116] EXT4-fs (dm-4): Remounting filesystem read-only

Po wycofaniu się z terenu instancji EC2 Docker zgłasza to: (z docker info)

Pool Name: docker-docker--pool
Pool Blocksize: 524.3 kB
Base Device Size: 107.4 GB
Backing Filesystem: ext4
Data file:
Metadata file:
Data Space Used: 12.73 GB
Data Space Total: 12.73 GB
Data Space Available: 0 B
Metadata Space Used: 3.015 MB
Metadata Space Total: 16.78 MB
Metadata Space Available: 13.76 MB
Thin Pool Minimum Free Space: 1.273 GB

LVS zrzuca te informacje:

  --- Logical volume ---
  LV Name                docker-pool
  VG Name                docker
  LV UUID                xxxxxxxxxxxxxxxxxxxxxxxxxxxx
  LV Write Access        read/write
  LV Creation host, time ip-10-0-0-65, 2017-03-25 22:37:38 +0000
  LV Pool metadata       docker-pool_tmeta
  LV Pool data           docker-pool_tdata
  LV Status              available
  # open                 2
  LV Size                11.86 GiB
  Allocated pool data    100.00%
  Allocated metadata     17.77%
  Current LE             3036
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:2

Co to jest ta cienka pula, dlaczego się wypełnia i jak mam temu zapobiec? Ponadto, jeśli mam ponad 20 GB wolnego miejsca w pojemniku na moim / woluminie, dlaczego to zatrzymuje nowe zapisy? O ile wiem, nie jest podłączony do plików, do których piszą moje programy.

Dziękuję Ci!

.ebextensionsSugerowane przez Davida Ellisa pracował dla mnie. Nie mogę skomentować jego odpowiedzi, ale chciałem dodać, że możesz utworzyć nowy wolumin EBS zamiast używać migawki. Aby zamontować wolumin EBS o pojemności 40 GB, zastosowałem:

option_settings:
  - namespace: aws:autoscaling:launchconfiguration
    option_name: BlockDeviceMappings
    value: /dev/xvdcz=:40:true

Zobacz także tę dokumentację , która zawiera przykład mapowania nowego woluminu EBS 100 GB na /dev/sdh.

Na truekońcu oznacza „usuń przy zakończeniu”.

Utworzyłem nowy .ebextensionskatalog zawierający ebs.configplik z powyższym kodem, a następnie spakowałem go wraz z moim Dockerrun.aws.json. Pamiętaj, że plik Dockerrun musi znajdować się na najwyższym poziomie pliku zip, a nie w podkatalogu.

Aby dowiedzieć się, gdzie Elastic Beanstalk montuje wolumin, użyj lsblkgo w wystąpieniu awarii. To też było /dev/xvdczdla mnie, więc może to jest standard.

Dotknął nas ten sam problem. Główną przyczyną wydaje się być to, że Docker nie instaluje silnika pamięci ( devicemapperdomyślnie alokowany elastycznie w Elastic Beanstalk) z discardopcjami, które z kolei wypełniają bloki, aż się zepsują.

Nie byłem w stanie znaleźć ostatecznego rozwiązania tego problemu, ale oto obejście (patrz ten komentarz ), które mogłem zastosować w przypadku wystąpień, których dotyczy problem:

docker ps -qa | xargs docker inspect --format='{{ .State.Pid }}' | xargs -IZ fstrim /proc/Z/root/

Postępowałem zgodnie z sugestiami dotyczącymi dokumentacji AWS i wszystko działa teraz.
Ale musiałem połączyć dwa rozwiązania: zwiększyć przestrzeń i dodać cronjob, aby usunąć stare pliki.
Oto co zrobiłem.

Najpierw zmieniłem głośność xvdczna 50 GB zamiast 12 GB. To miejsce, w którym możemy zobaczyć docker system info. W moim przypadku zawsze było pełne, ponieważ codziennie przesyłam wiele plików.

.ebextensions / blockdevice-xvdcz.config

option_settings:
  aws:autoscaling:launchconfiguration:
    BlockDeviceMappings: /dev/xvdcz=:50:true

Po dodaniu pracy zespołowej do czyszczenia usuniętych plików, które nie były już używane. Było to wymagane, ponieważ Docker nadal je trzymał z jakiegoś powodu. W moim przypadku wystarczy raz dziennie. Jeśli masz więcej przesłanych plików niż ja, możesz skonfigurować cronjob do uruchamiania tyle razy, ile potrzebujesz.

.ebextensions / cronjob.config

files:
    "/etc/cron.d/mycron":
        mode: "000644"
        owner: root
        group: root
        content: |
            0 23 * * * root /usr/local/bin/remove_old_files.sh

     "/usr/local/bin/remove_old_files.sh":
        mode: "000755"
        owner: root
        group: root
        content: |
            #!/bin/bash
            docker ps -q | xargs docker inspect --format='{{ .State.Pid }}' | xargs -IZ sudo fstrim /proc/Z/root/
            exit 0

 commands:
    remove_old_cron:
        command: "rm -f /etc/cron.d/*.bak"

Źródło: https://docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/create_deploy_docker.container.console.html#docker-volumes

AWS sekcja elasticbeanstalk doker konfiguracji środowiska dokumenty jak to działa:

Aby zwiększyć wydajność, Elastic Beanstalk konfiguruje dwa woluminy magazynu Amazon EBS dla instancji EC2 środowiska Docker. Oprócz woluminu głównego udostępnionego dla wszystkich środowisk Elastic Beanstalk, drugi wolumin 12 GB o nazwie xvdcz jest przewidziany do przechowywania obrazów w środowiskach Docker.

Jeśli potrzebujesz więcej miejsca do przechowywania lub zwiększonego IOPS dla obrazów Docker, możesz dostosować wolumin do przechowywania obrazów, używając opcji konfiguracji BlockDeviceMapping w aws: automatyczne skalowanie: przestrzeń nazw konfiguracji konfiguracji.

Na przykład następujący plik konfiguracyjny zwiększa rozmiar woluminu do 100 GB przy 500 inicjowanych IOPS:

Przykład .ebextensions / blockdevice-xvdcz.config

option_settings:
  aws:autoscaling:launchconfiguration:
    BlockDeviceMappings: /dev/xvdcz=:100::io1:500

Jeśli użyjesz opcji BlockDeviceMappings do skonfigurowania dodatkowych woluminów dla swojej aplikacji, powinieneś dołączyć mapowanie dla xvdcz, aby upewnić się, że zostanie ono utworzone. Poniższy przykład konfiguruje dwa woluminy, wolumin pamięci obrazu xvdcz z ustawieniami domyślnymi i dodatkowy wolumin 24 GB o nazwie sdh:

Przykład .ebextensions / blockdevice-sdh.config

option_settings:
  aws:autoscaling:launchconfiguration:
    BlockDeviceMappings: /dev/xvdcz=:12:true:gp2,/dev/sdh=:24

Od ponad dnia uderzyłem się w głowę tym problemem i w końcu to rozgryzłem.

AWS korzysta z devicemapperbackendu i tworzy wolumin SSD o pojemności 12 GB, który montuje i używa dla obrazów dokera. Musisz zastąpić wolumin, który zamontowałby za pomocą koncepcji rozszerzeń elasticbeanstalk i wdrożyć za pośrednictwem interfejsu CLI (niestety nie można tego zrobić za pomocą interfejsu GUI).

W katalogu, w którym znajduje się Dockerrun.aws.jsonplik, utwórz katalog o nazwie, .ebextensionsa następnie utwórz plik, który kończy się w .confignim. Zadzwoniłem do mnie 01.correctebsvolume.config. Następnie umieść tam następującą zawartość:

option_settings: - namespace: aws:autoscaling:launchconfiguration option_name: BlockDeviceMappings value: /dev/xvdcz=snap-066cZZZZZZZZ:40:true:gp2

Wsadziłem bezpośrednio do jednego z moich wadliwych pudełek i stwierdziłem, że się montuje /dev/xvdcz. To mogą być różne dla Ciebie. Że snap-066cZZZZZZZZmusi być poprawny identyfikator migawka. Utworzyłem obraz AMI instancji powodującej błąd i użyłem migawki, którą utworzyłem w tym procesie. To, 40ile GB będzie wolumin, więc zastąp to, czego potrzebujesz. Nie wiem, co truelub gp2robię, ale pochodzą one z danych urządzenia blokowego obrazu AMI, więc je zachowałem.

Magia namespacei option_namepochodzą stąd w dokumentacji.

Zwiększenie rozmiaru dysku nie rozwiąże problemu, po prostu popełni błąd. AWS zaleca mapowanie nowego dysku do kontenera, aby żaden plik tworzenia / usuwania nie wpływał na warstwę ankiety Docker.

Obecnie patrzę na to, jeszcze nie testowałem, ale rozwiązaniem, które napotkałem, jest to na moim blockdevice.config

commands:
  01mount:
    command: "mount /dev/sdh /tmp"
option_settings:
  aws:autoscaling:launchconfiguration:
    BlockDeviceMappings: /dev/xvda=:16:true:gp2,/dev/xvdcz=:12:true:gp2,/dev/sdh=:12:true:ephemeral0

Doceń wszelkie komentarze.