Büyük Soruna Hızlı Çözüm “Ansible SRM Modülü” 🚀


    Herkese Selamlar,

    Bugün Ansible için oluşturmuş olduğumuz SRM modüllerinin macerasını ve nasıl kullanılabileceğimize dair bir yazı kaleme alacağım. Manual kullanımı bile zor ve yorucu olan SRM süreçlerinin ansible ile bir custom modül oluşturarak otomatik olarak nasıl çözdük ve hatta bunu da takvimli bir çalışmaya bağlayarak SRM testlerimizi uçtan uca insan müdahalesi olmadan nasıl gerçekleştirdik ?

    Öncelikle kullanılan ürünleri anlamak açısından biraz anlatalım.

    VMware Site Recovery Manager (SRM) Nedir?
    https://www.vmware.com/products/site-recovery-manager.html

    VMware Site Recovery Manager (SRM), sanal makine (VM) kurtarma ve iş sürekliliği için otomatikleştirilmiş bir çözüm sunan bir üründür. Sanal ortamlarda felaket sonrası kurtarma süreçlerini kolaylaştırır. Temel olarak, birincil veri merkezinizde bir sorun olması durumunda, VM’lerinizi önceden belirlenen bir felaket kurtarma (DR) lokasyonuna otomatik olarak taşıyabilir veya kopyalayabilir.

    SRM, felaket kurtarma senaryolarını test etmek için de olanak tanır. Bu, gerçek bir felaket durumunda iş sürekliliğini garantilemek için kritik öneme sahiptir. SRM, VMware vSphere ortamıyla entegre bir şekilde çalışarak, kullanıcıların DR stratejilerini etkili ve güvenilir bir şekilde yürütmelerine yardımcı olur.

    Ansible Nedir?
    https://docs.ansible.com/

    Ansible, açık kaynaklı bir otomasyon aracıdır ve genellikle yapılandırma yönetimi, uygulama dağıtımı, görev otomasyonu ve IT altyapısının otomasyonunda kullanılır. Temel özelliği, karmaşık görevleri ve iş akışlarını basit ve anlaşılır “playbook” adı verilen yapılandırmalarla otomatikleştirmesidir.

    Ansible’ın en büyük avantajlarından biri, ajan tabanlı olmayan bir yaklaşım benimsemesidir. Bu, yönetilen makinelerde özel bir yazılımın yüklenmesine gerek olmadığı anlamına gelir. Ansible, SSH (Linux/Unix için) veya WinRM (Windows için) üzerinden makinelerle iletişim kurar.

    Yaml dilinde yazılan playbook’lar sayesinde, kullanıcılar, altyapılarını istedikleri hedef duruma getirebilirler. Ayrıca, Ansible, modüler bir yapıya sahip olduğu için kullanıcının ihtiyacına özel modüller oluşturmasına da olanak tanır.


    Ansible modül oluşturma?

    Ansible geliştiricilerinin gözünü korkutan bu konu aslında bir PYTHON geliştirmesinden ibaret basit bir yapıdır. Program için gerekliliklerimiz kullanıcı etkileşimi , yapılacak iş ve hata yönetimidir.

    1. Kullanıcı etkileşimi, yazılacak yaml da geliştiricinin girdiği değerlere denk geliyor. Ansible modül oluşturma için kullanılacak bir kütüphane ile bu parametreler kolay şekilde yaml ile alınabilir. Burada parametrelerin tipleri, seçimleri, zorunlu olup olmadığı belirtilebilir.
    2. Kullanıcıdan inputu aldık peki sırada ne var? Sırada asıl işin yapılması yani SRM özelinde, srm geçişlerini yapacak fonksiyonu devreye almak var. Bunu da test ettikten sonra artık elimizde fonksiyonel bir srm modülü var diyebiliriz. Kullanıcıdan bir input alan mesela vm adını vmware adresini alan ve SRM RUN senaryosunu çalıştıran bir ansible modülü var.
    3. Buraya kadar her şey mükemmel giderse bir sorunumuz olmaz. Peki ya karşımıza hata çıkarsa . Vmware SRM’e bağlanamazsak veya VM’i SRM’ de bulamazsak ya da kullanıcımızın yetkisi yoksa neler yapmalıyız. Burada da karşımıza hata yönetimi çıkıyor. Modülü kullanacak geliştiricilerin karşılaşacakları hatalarını iyi adreslememiz gerekiyor.

    Bu sorunu da atlattığımız zaman modülümüzü test işlemlerine tabi tutabiliriz.

    Ben de tam olarak bu aşamaları takip ederek Ansible SRM modülünü oluşturdum.

    Oluşturmuş olduğum SRM rest modüllerinin şu an için yapabilecekleri aşağıdadır!

    1. SRM Get Replication
    2. SRM Delete Replication
    3. SRM Delete PG
    4. SRM Delete RP
    5. SRM Run & Reprotect
    6. SRM Test
    7. SRM Cleanup


    Test aşamasında, modül oluşturmada VMware tarafında çok fazla uzman desteğine ihtiyaç duydum. Çünkü SRM’in tepkisini kestirebilmem ve modül kullanımındaki hataları giderebilmem gerekiyordu. Ayrıca modül parametrelerinin modülü kullanacaklar için anlaşılır olması da gerekiyordu. Burada da devreye Sanallaştırma Mühendisi Orhan Akyüz devreye girdi.

    Orhan Akyüz ile birlikte geliştirdiğimiz bu modüllerle en nihayetinde manual olarak yönetilmesi bile çok zor olan bir süreci otomatik, hızlı, hataları adresleyebileceğimiz bir modül grubu haline getirmiş olduk. Hala çeşitli ihtiyaçlar dahilinde buraya yeni custom modüller yazmaktayız.

    VMware SRM’in dokümantasyonuna göre yazılmış modüller kolayca istenildiği şekilde güncellenebilmektedir.

    SRM modülü kullanılarak ve URI ile replikasyonları getirme yaml’ları aşağıdaki gibidir. Modül sadece daha hızlı ve etkili bir çözüm sunmuyor ayrıca sizin için hataları ayıklayıp sizin çok daha kolay bir şekilde bu hataları yönetmenizi ve gidermenizi sağlıyor.

    SRM Get Replication With URI

    - name: SRM GET Replication With URI
      hosts: localhost
      tasks:
        - name: Authenticate
          uri:
            url: "<session_url>"
            user: "<srm_user>" 
            password: "<srm_password>"
            method: POST
            follow_redirects: none
            force_basic_auth: yes
            validate_certs: False
            status_code: [200,201,202,203,204]
            body_format: json
            headers:
              Content-Type: "application/json;charset=utf-8"
          register: result
        - name: Get Replications
          uri:
            url: "<srm_replication_url>"
            user: "<srm_user>"
            password: "<srm_password>"
            method: GET
            follow_redirects: none
            force_basic_auth: yes
            validate_certs: False
            status_code: [200,201,202,203,204]
            headers:
              Content-Type: "application/json;charset=utf-8"
              x-dr-session: "{{ result.json.session_id }}"
          register: replications
        - name: Fail if '{{ server_name }}' is not in list 
          fail:
            msg: " {{ server_name }} is not found on srm replication"
          when: replications.json.list | map(attribute='name') | select('equalto','{{ server_name }}') | list | length == 0

    SRM Get Replication With SRM Module

    - name: SRM Get Replication
      hosts: localhost
      gather_facts: no
      tasks:
       - name: Get Replication With SRM module
         community.cnrzdr.srm_get_replications: 
          ip: "<srm_url>"
          user: '{{ lookup("env", "ANSIBLE_NET_USERNAME") }}'
          password: '{{ lookup("env", "ANSIBLE_NET_PASSWORD") }}'
          rest_type: "<rest_type>"
          pairing_id: "<pairing_id>"

    SRM modülünün DRC çalışmalarında takvimli olarak çalıştırılması ?

    Oluşturulan custom modül DRC testlerinde kullanılanabilmektedir.
    Örneğin gece saat 3’te DRC ortamına geçirilecek ve orada reprotect edilecek VM’leriniz var. SRM modülümüz ve Ansible Schedules job ile geçişi otomatik ve istenilen saatte gerçekleştirebilir ve ardından yine modül ile otomatik olarak reprotect edebiliriz. VM’ler 5 saat DRC ortamında çalıştırıldıktan sonra sabah 8’de tekrar PROD ortama otomatik olarak yine takvimli bir şekilde geri getirilip ve burada yine reprotect ederek modülümüzü burada başarılı şekilde kullanmış olabiliriz. Uçtan uça hiçbir insan müdahalesi olmadan DRC testlerimizi gerçekleştirebiliriz.

    Sonraki yazımda ansible ile güvenlik ürünlerinin entegrasyonu ve güvenlik ürünleri ile çeşitli kullanım örneklerinden bahsedeceğim.

    Yazımı okuduğunuz için teşekkür ederim umarım herkes için aydınlatıcı olmuştur.
    #ansible #devops #srm #automation #community #redhat #yaml

    Leave a Reply

    Your email address will not be published. Required fields are marked *