Как да стартирате Ethereum Mainnet възел на AWS

Наскоро AWS публикува шаблони CloudFormation [1], за да стартира частна мрежа за тестване на Ethereum.
Тяхното решение идва с приложение за преглед на блокове, миньор и т.н. Колкото и да е страхотно, това решение не е лесно да се приложи за стартиране на възел на главна мрежа.

Първо, нека се опитаме да отговоря защо някой ще се нуждае от частен хост Ethereum възел, вместо да разчита на Infura. В Rumble Fish имаме няколко проекта, в които някой компонент за гръб взаимодейства
с блокчейн Ethereum. В някои случаи той реагира на уведомление за събитие, в други е отговорен за приключване на финансовата транзакция и трябва да действа бързо.

Никога не е добра идея да накарате бизнес критичните процеси да разчитат на това, че външната услуга работи добре. Каквото и да се случи с Инфура, е извън нашия контрол. Ако падне там, можеше само да почака. Това може да не е проблем за много приложения, в нашия случай трябваше да премахнем този риск.

TL; DR обобщение

За да стигнете възела, следвайте точка по-долу. Предполага се, че имате AWS акаунт, създаден с програмен достъп.

0. Клонирайте това хранилище.

git clone https://github.com/rumblefishdev/cf-parity-mainnet.git
  1. Отворен терминал. Инсталирайте aws и jq, ако не са инсталирани.
  2. Задайте с кой акаунт и регион работите.
експортиране AWS_DEFAULT_REGION = eu-central-1
      # настроен на съвпадение на запис в ~ / .aws / идентификационни данни
      експортиране AWS_DEFAULT_PROFILE = ...

3. Създайте хранилище, изградете изображение и го натиснете.

bash build_and_upload.sh

Тази команда създава ECR хранилище под вашия акаунт и бута там леко персонализирано изображение на Parity клиент.

4. Посочете параметрите на възела.

cd облачност
cp stack-settings.default.json stack-settings.json
$ EDITOR стек-параметри.json

Тук трябва да посочите:

  • VpcId за стартиране на веригата
  • DNSName да се регистрирате за вашия възел (напр. Mainnet.rumblefishdev.com)

5. Създайте стека на CloudFormation.

bash -x create-stack

6. Отидете на конзолата CloudFormation и изчакайте да завърши създаването на стека. Вземете изнесения NameServer изход и го поставете като NS запис в DNS конфигурацията на вашия домейн.

7. Изчакайте ~ 3 дни за приключване на процеса на синхронизация и проверка.

8. Отидете на конзолата AWS EC2 | Раздел „Обеми“ и направете обемна снимка.

9. Когато моментната снимка е готова, поставете я като параметри ChainSnapshodId stack-settings.json и актуализирайте стека.

bash -x update-stack

Предизвикателства на работещия възел на mainnet

Устойчивост на блокчейн данни

Най-голямото предизвикателство за получаване на мрежовия възел е синхронизирането му. Синхронизирането на ново свързан възел от нула отнема 2-3 часа, за да стигнете до текущите блокове. След това са необходими допълнителни 2-3 дни, за да завършите процеса на криптографска проверка на всички блокове. Процесът на проверка използва всички налични IOPS, което прави възела не много отзивчив. През това време често се наблюдава, че възелът ще изостава с до 30 блока, което го прави не полезен. Едва след приключване на процеса на проверка възелът става стабилен и може да се разчита на него. Стековете, предлагани от AWS, не решават този проблем - всеки възел започва с чист лист. Това е добре, стига да нямате много данни, които да синхронизирате от други възли.

Тъй като "струва" ~ 3 дни за стартиране на новия възел, е необходимо да се поддържат данни между рестарти на възела. Със сигурност има повече от един начин да се постигне това. Решението, което предлагаме, е да съхранявате верижните данни на EBS устройството и да правите моментна снимка от него, след като блокчейнът се синхронизира напълно. Ако даден възел бъде прекратен и нов го поеме, той ще трябва да синхронизира блоковете само от моменталната снимка, а не цели 3 години история на веригата.

Ясно е, че не е идеално и бихме предпочели да имаме постоянни данни и никога не трябва да синхронизираме блокове, въпреки че досега намерихме идеално решение.

Подходи, които сме уволнили

Единична устойчива EBS

Едно нещо, което се опитахме, е да създадем устойчив EBS обем извън контекста на EC2 машината и да го свържем с възел при стартиране. Този подход има своите предимства. Когато машината се прекрати и се завърти нова, тя започва, когато другата изгасне. Това е чудесната функция, защото прави забавянето на повторната синхронизация минимално.

От обратната страна този подход не се справя добре с мащабирането на броя на случаите нагоре и надолу. В сценарий, при който бихме искали да имаме повече възли, които да променят или балансират натоварването, ще трябва да добавим допълнителен слой, за да решим кой EBS диск да използва или евентуално да създаде нов. Отхвърлихме го като твърде сложно.

Еластична файлова система (EFS)

Друг интересен опит за решаване на проблема с мащабирането беше използването на EFS. За разлика от EBS, той може да бъде свързан към множество инстанции, които го споделят с помощта на протокол, подобен на NFS. За съжаление видяхме, че възлите с верижни данни на EFS са необходими завинаги за синхронизиране. Паритетът използва много IOPS, а EFS предлага много по-ниска производителност от EBS.

Достъп на обществена мрежа за синхронизиращ слой

За да бъде синхронизиран възелът, той трябва да може да приема връзки от други възли. Е, за да бъдем напълно строги, изисква се само едната страна на връзката да приема връзки, така че технически да работим без. Въпреки това, ние прескочихме публичния достъп, тъй като възелът ни можеше да работи само с възли, предлагащи обществен достъп, което елиминира голямо парче от партньорския пул.

За да осигурим обществен достъп, използвахме следните стъпки.

  1. Паритетът се изпълнява в докер контейнер. Порт 30303 се мостира, като се използва следната част от стека на облачната информация.
ресурси:
  TaskDefinition:
    Тип: AWS :: ECS :: TaskDefinition
    Имоти:
      ...
      ContainerDefinitions:
        ...
        PortMappings:
          - ContainerPort: 30303
            HostPort: 30303
            Протокол: tcp

2. Възелът вече има нужда от своя публичен IP, тъй като това се използва като идентификатор на кодиране, излъчван към други възли. Решението е специфично за EC2 и разчита на вътрешния API, наличен от машината. От docker / run_parity.sh:

PUBLIC_IP = `curl -s http: // 169.254.169.254 / най-нови / метаданни / public-ipv4`
/ parity / parity --config config.toml --nat extip: $ PUBLIC_IP

3. За да е достъпът на порта на EC2 машината, той също трябва да се отвори в конфигурация на групата за сигурност. Тази част от стека е отговорна за това, което прави точно това.

ресурси:
  ECSSecurityGroup:
    Тип: AWS :: EC2 :: SecurityGroup
    Имоти:
      ...
      SecurityGroupIngress:
        - FromPort: 30303
          ToPort: 30303
          CidrIp: 0.0.0.0/0
          IpProtocol: tcp

Частен достъп до крайните точки на json-rpc и websocket

Паритетът има още два мрежови интерфейса за достъп до данни от blockchain.

  • порт 8545 се използва за json-rpc api: публикуване на транзакции и получаване на всякакъв вид информация
  • порт 8546 може да се използва за получаване на известия от възела за нови блокове и / или събития

Първо нека да обсъдим защо смятаме, че json-rpc не трябва да бъде обществено достъпен. В зависимост от конкретния случай на използване може да не е проблем да се отвори json-rpc. Въпреки това в Rumble Fish вярваме, че всичко, което може да бъде скрито, трябва да остане скрито.

Оставянето на отворена крайна точка json-rpc не поставя в опасност никакви средства. Поне има някаква фундаментална грешка в Parity, която все още не е открита. Въпреки това е лесно да си представим, че нападател може просто да изпълни много заявки на възела, само за да предотврати законното му използване. Ето защо вярваме, че си струва да положим допълнителни усилия, за да направим тази част по-сигурна.

Нашият подход за частен достъп се състои в следното.

  1. Облакът за формиране на облак създава и експортира специална SecurityGroup, използвана за достъп до възела. Можете да го импортирате друг стек, като използвате:
! Fn :: Импортиране на MainnetPinity-AccessSecurityGroup

2. Тази група получава достъп до инстанцията, като използва следните настройки в SecurityGroup на EC2 инстанцията.

ресурси:
   ECSSecurityGroup:
     Тип: AWS :: EC2 :: SecurityGroup
     Имоти:
       ...
       SecurityGroupIngress:
         - FromPort: 8545
           ToPort: 8545
           SourceSecurityGroupId:! GetAtt AccessSecurityGroup.GroupId
           IpProtocol: tcp
         - FromPort: 8546
           ToPort: 8546
           SourceSecurityGroupId:! GetAtt AccessSecurityGroup.GroupId
           IpProtocol: tcp


Тези портове се пренасочват към контейнера на докер, подобно на това, което сме правили преди
порт 30303.

::

  ресурси:
    TaskDefinition:
      Тип: AWS :: ECS :: TaskDefinition
      Имоти:
        ...
        ContainerDefinitions:
          ...
          PortMappings:
            - ContainerPort: 8545
              HostPort: 8545
              Протокол: tcp
            - ContainerPort: 8546
              HostPort: 8546
              Протокол: tcp

3. Клиентът, свързващ се с json-rpc / websocket api, трябва да направи това, като използва частен IP на инстанцията. Ние постигаме това чрез създаване на Route53 HostedZone и регистрираме IP адреси на инстанции там при стартиране.

Стека на облачната информация експортира сървърите на имена на тази зона, които трябва да бъдат импортирани като

! Fn :: Импортиране на MainnetPITY-NameServer

или потърсих в износа на конзолата AWS

Трябва да поставите тази стойност като NS запис в конфигурацията на вашия DNS домейн.

Мониторинг и дърводобив

Стекът е конфигуриран да събира интересни файлове от машината и да ги избутва към поток от регистър на CloudWatch, наречен MainnetPality-logs.

Процес на синхронизиране и потвърждаване

Тук интересните битове са имената на файловете / parity / parity / ..., които са изход от процеса на паритет. Първият път, когато стартирате стека, той ще използва warp sync, за да изтегли историята на blockchain, използвайки протокола за групово изтегляне на Parity.

В изхода изглежда някак така:

2018-05-11T09: 27: 56.202Z ++ къдряне -s http://169.254.169.254/latest/meta-data/public-ipv4
2018-05-11T09: 27: 56.253Z + PUBLIC_IP = 18.196.95.41
2018-05-11T09: 27: 56.253Z + / паритет / паритет --config config.toml --на краен срок: 18.196.95.41
2018-05-11T09: 27: 56.297Z Зареждане на конфигурационен файл от config.toml
2018-05-11T09: 27: 56.350Z 2018-05-11 09:27:56 UTC Начален Паритет / v1.10.3-стабилен-b9ceda3-20180507 / x86_64-linux-gnu / rustc1.25.0
2018-05-11T09: 27: 56.350Z 2018-05-11 09:27:56 UTC Ключ път /root/.local/share/io.parity.ethereum/keys/Foundation
2018-05-11T09: 27: 56.350Z 2018-05-11 09:27:56 UTC DB path /root/.local/share/io.parity.ethereum/chains/ethereum/db/906a34e69aec8c0d
2018-05-11T09: 27: 56.350Z 2018-05-11 09:27:56 UTC Път към dapps /root/.local/share/io.parity.ethereum/dapps
2018-05-11T09: 27: 56.350Z 2018-05-11 09:27:56 UTC Конфигурация на състоянието на DB: бързо
2018-05-11T09: 27: 56.350Z 2018-05-11 09:27:56 UTC Режим на работа: активен
2018-05-11T09: 27: 56.361Z 2018-05-11 09:27:56 UTC Конфигуриран за Foundation с помощта на двигателя Ethash
2018-05-11T09: 27: 56.730Z 2018-05-11 09:27:56 UTC URL адрес на публичен възел: enode: //ec52f4ae94c624b1f8bf9c9b60fd63261beb42af6fea9d0fa4aeb6f52047fdf4afd92d9e3cd9c0f9f9389389385385385387fbfbdddddddddddbddddddddddddddddddbddddbddbddbbdbddbdbddbdbddbdbddbdbdbbdbdbbbdbdbdbbbbb, 5, 5, -0, ф-т
2018-05-11T09: 27: 57.057Z 2018-05-11 09:27:57 UTC Обновен курс на конверсия до Ξ1 = 694,89 US $ (6852745,5 wei / газ)
2018-05-11T09: 28: 06.806Z 2018-05-11 09:28:06 UTC Синхронизиране # 0 d4e5… 8fa3 0 blk / s 0 tx / s 0 Mgas / s 0+ 0 Qed # 0 1/25 връстници 8 KiB верига 3 MiB db 0 байта опашка 10 KiB синхронизация RPC: 0 conn, 0 req / s, 0 µs
2018-05-11T09: 28: 16.806Z 2018-05-11 09:28:16 UTC Синхронизиране на моментна снимка 9/1370 # 0 2/25 връстници 8 KiB верига 3 MiB db 0 байта опашка 10 KiB синхронизация RPC: 0 conn, 0 req / s, 0 µs
2018-05-11T09: 28: 21.807Z 2018-05-11 09:28:21 UTC Снимка на синхронизиране 15/1370 # 0 2/25 връстници 8 KiB верига 3 MiB db 0 байта опашка 10 KiB синхронизация RPC: 0 conn, 0 req / s, 0 µs
2018-05-11T09: 28: 26.808Z 2018-05-11 09:28:26 UTC Синхронизиране на моментна снимка 21/1370 # 0 2/25 връстници 8 KiB верига 3 MiB db 0 байта опашка 10 KiB синхронизация RPC: 0 conn, 0 req / s, 0 µs
2018-05-11T09: 28: 31.809Z 2018-05-11 09:28:31 UTC Синхронизиране на моментна снимка 27/1370 # 0 3/25 връстници 8 KiB верига 3 MiB db 0 байта опашка 10 KiB синхронизация RPC: 0 conn, 0 req / s, 0 µs
2018-05-11T09: 28: 36.809Z 2018-05-11 09:28:36 UTC Синхронизиране на моментна снимка 29/1370 # 0 3/25 връстници 8 KiB верига 3 MiB db 0 байта опашка 10 KiB синхронизация RPC: 0 conn, 0 req / s, 0 µs

Процесът на синхронизиране на снимките отнема около 3 часа. След синхронизирането на снимките Parity ще изтегли всички блокове, създадени от последната снимка до текущата глава на blockchain. Тази фаза изглежда така:

2018-05-11T10: 26: 46.793Z 2018-05-11 10:26:46 UTC Синхронизиране на моментна снимка 1327/1370 # 0 26/50 връстници 8 KiB верига 3 MiB db 0 байта опашка 10 KiB синхронизация RPC: 0 conn, 0 req / s, 0 µs
2018-05-11T10: 26: 56.798Z 2018-05-11 10:26:56 UTC Синхронизиране на моментна снимка 1346/1370 # 0 26/50 връстници 8 KiB верига 3 MiB db 0 байта опашка 10 KiB синхронизация RPC: 0 conn, 0 req / s, 0 µs
2018-05-11T10: 27: 08.097Z 2018-05-11 10:27:08 UTC Синхронизиране # 5590000 b084… 309c 0 blk / s 0 tx / s 0 Mgas / s 0+ 0 Qed # 5590000 24/25 връстници 63 KiB верига 1 KiB db 0 байта опашка 6 MiB синхронизация RPC: 0 conn, 0 req / s, 0 µs
2018-05-11T10: 27: 16.794Z 2018-05-11 10:27:16 UTC Синхронизиране # 5590000 b084… 309c 0 blk / s 0 tx / s 0 Mgas / s 1750+ 1 Qed # 5591752 26/50 връстници 174 KiB верига 39 KiB db 95 MiB опашка 11 MiB синхронизация RPC: 0 conn, 0 req / s, 0 µs

Това ще отнеме около още час, за да завършите този етап.

Когато тази фаза приключи, лог файлът ще се промени така:

2018-05-11T15: 24: 30.011Z 2018-05-11 15:24:30 UTC Синхронизиране # 5595608 f2fe… d003 0 blk / s 0 tx / s 0 Mgas / s 0+ 7 Qed # 5595619 11/25 връстници 33 MiB верига 182 MiB db 1 MiB опашка 8 MiB синхронизация RPC: 0 conn, 0 req / s, 0 µs
2018-05-11T15: 24: 41.386Z 2018-05-11 15:24:41 UTC Обновен курс на конверсия до Ξ1 = US $ 679.41 (7008882.5 wei / газ)
2018-05-11T15: 24: 41.795Z 2018-05-11 15:24:41 UTC Импортирани # 5595620 ef95… d8b2 (181 txs, 7.98 Mgas, 4237.27 ms, 27.63 KiB) + още 3 блока (и), съдържащи 330 tx (с)
2018-05-11T15: 24: 48.290Z 2018-05-11 15:24:48 UTC Импортирани # 5595622 221b… 509d (162 txs, 7.99 Mgas, 1194.76 ms, 25.13 KiB)
2018-05-11T15: 24: 51.186Z 2018-05-11 15:24:51 UTC Импортирани # 5595623 b744… cf9c (183 txs, 7.98 Mgas, 1698.02 ms, 33.23 KiB)
2018-05-11T15: 25: 27.225Z 2018-05-11 15:25:27 UTC # 40653 13/25 връстници 37 MiB верига 182 MiB db 0 опашка байта 24 MiB синхронизация RPC: 0 conn, 0 req / s, 0 микросименса
2018-05-11T15: 25: 27.241Z 2018-05-11 15:25:27 UTC # 40653 13/25 връстници 37 MiB верига 182 MiB db 0 опашка за байтове 24 MiB синхронизиране RPC: 0 conn, 0 req / s, 0 микросименса
2018-05-11T15: 25: 27.252Z 2018-05-11 15:25:27 UTC # 40653 13/25 връстници 37 MiB верига 182 MiB db 0 опашка байта 24 MiB синхронизация RPC: 0 conn, 0 req / s, 0 микросименса
2018-05-11T15: 25: 27.310Z 2018-05-11 15:25:27 UTC # 40653 13/25 връстници 37 MiB верига 182 MiB db 0 опашка байта 24 MiB синхронизация RPC: 0 conn, 0 req / s, 0 микросименса
2018-05-11T15: 25: 41.464Z 2018-05-11 15:25:41 UTC Импортирани # 5595627 a4a9… 9dc0 (136 txs, 7.98 Mgas, 529.92 ms, 19.68 KiB)
2018-05-11T15: 26: 02.263Z 2018-05-11 15:26:02 UTC # 78637 23/25 връстници 37 MiB верига 183 MiB db 241 KiB опашка 22 MiB синхронизация RPC: 0 conn, 0 req / s, 0 микросименса
2018-05-11T15: 26: 03.398Z 2018-05-11 15:26:03 UTC Reorg to # 5595628 8fc3… 7c58 (a4a9… 9dc0 18c7… 4d47 # 5595625 f6c1… feae 3faf… 012d af04… 83a8)

Новият тип логлин, започващ с номера на блока (# 40653 ..) идва от процеса на проверка на изтеглените блокове. В този процес Parity проверява всяка блокова криптография и гарантира, че никой не се подправя на данните.

Този процес отнема около 3 дни твърде завършен, когато се работи на t2.machine с gp2 EBS 300 IOPS. Докато работи, можете да наблюдавате при мониторинга на EBS обема, че всички налични IOPS се консумират. Екранната снимка по-долу представя момента на приключване на процеса на проверка. Можете да видите разликата в модела на използване.

Прочетете IOPSНапишете IOPS

Тъй като процесът на проверка е свързан с IO, е възможно да се ускори чрез осигуряване на EBS устройството с допълнителни IOPS. В нашия стек в CloudFormation използваме gp2 VolumeType с размер 100 GB. AWS предвижда 300 базови IOPS за такова устройство. Ако трябва да направите проверката по-бърза, можете да промените VolumeType до io1 и да й дадете 1200 IOPS. На това ниво наблюдаваме, че процесът на проверка вече не се ограничава от наличните IOPS, но липсва мощността на процесора. Следователно можете да го поставите на друго ниво, като промените размера на EC2 машината от t2.medium на c5.large.

Правейки на c5.large забелязахме, че Parity по време на проверката използва 2000 IOPS и може да завърши целия процес за около 7 часа, така че е добър пряк път, ако трябва бързо да имате резултати. Само имайте предвид, че предвидените IOPS не са евтини, месечните разходи за оставяне на диск с такъв размер и IOPS ще бъдат в диапазон от 100 долара, така че бъдете внимателни.

Идеята е, че след като синхронизирането и проверката приключи, можете да направите моментна снимка и да я използвате за рестартиране на клъстера с типа на диска и машината.

Поддържане на синхрон

След като възелът е напълно синхронизиран и синхронизиран, той обикновено остава в синхрон с главата на веригата :-)

Паритетът се различава от Infura

Изображението по-горе представя ефект от извикване eth_blockNumber на нашия възел и на Infura. През повечето време възлите са синхронизирани. Понякога или възелът ни, или Инфура пада на 1-4 блока зад.

Моля, обърнете внимание, че понастоящем това хранилище не включва Lambda, който отговаря за събирането на показатели по-горе. Това ще бъде включено в бъдещи статии.

[1] https://docs.aws.amazon.com/blockchain-templates/latest/developerguide/blockchain-templates-ethereum.html

Chcielibyście dowiedzieć się, jak uruchomić mainnetowy възел Ethereum на AWS, ale wolicie przeczytać o tym po polsku? Zapraszamy do zapoznania się z tłumaczeniem artykułu opublikowanym przez justgeek.it: https://geek.justjoin.it/uruchomic-mainnetowy-node-ethereum-aws/