Öne çıkan

Kuş Bakışı : ROMA

16-17 Haziran 2019

Korona yoktu, kanımız deli akıyordu o zamanlar arkadaşlar 🙂 Hadi kahvenizi alın, sizinle biraz gezelim.

Rotamız tarihiyle meşhur şehir: Roma.

2019 senesi benim için leyleği havada gördüğüm seneydi diyebilirim. Roma da bu seneden nasibini almış güzide şehirlerimizden. Normalde seyahatlerimi en erken 1 hafta öncesi planlarım ya da planı yola çıkarken yapmayı tercih ederim. Bu tarz şipşak gezilerin de avantaj ve dezavantajlarını bir başka yazımda bahsedeceğim. Roma gezime gelecek olursak, ilginç bir şekilde aylaaaaar öncesinde planladığım bir gezi. O zamanlar benim için düşük bütçeli seyahat zamanları. Ama ben yürek yiyerek bir otelden yer ayırtmışım. Son güne kadar da iptal etmeyi düşündüğüm bir otel idi. Kalacağınız yerden beklentiniz temiz bir yatak ve uyuyabilmek ise tavsiye edebilirim.

Otelin ismi: Backpackers Piramide. 1 gece için 22.50€ ödemiştim. Booking.com’ dan önceliğimin puanı yüksek, konaklamanın ucuz olanından filtreleyerek bulduğum bir otel. Wifi de fena çekmiyordu. Wifi demişken İtalya’da her şey gibi internet kullanım ücretinin de çok pahalı olduğunu belirtmek isterim. Polonya’da yüklediğim 100 zloty’lik kontör ile 1.5 ay Avrupa’yı gezdim. Yalnızca 30 zloty harcadım. İtalya’ya geldim ve 65 zloty 2 gün içinde bitiverdi. Ayrıca diğer Avrupa ülkelerinde puplic wifi noktaları çok yaygın. Ama özellikle Roma başta olmak üzere İtalya için bu durum geçerli değil. Bu sebeple benden tavsiye İtalya’yı gezerken paranız ve pasaportunuz gibi internetinize de sıkı sıkı sahip çıkın 😉

Toplam gezi sürem 2 tam gündü. Yeterli mi derseniz bence imkanınız ve zamanınız var ise 1 gün daha gezebilirsiniz. Ben tek başıma gezdiğim için zamanımın çoğunu görülmesi gereken önemli yerlere ayırıp, yemeği takeaway tercih ediyorum. Dinlenme kısmını da gezi bitinceye bırakıyorum. Bu sebeple benim 2 günüm sizin için 3 gün desek daha ideal olabilir.

Gelelim rotamıza!

Polonya’dan İtalya’ya uçak ile geçtim. Roma biletleri pahalı olduğu için önce Milano’ya uçtum. Ayrıca bahaneyle mini bir Milano turu da yapmak istemiştim. Onu da ayrı bir yazıda bahsetmeyi umuyorum. Neyse Milano’dan otobüs ile Roma’ya geçtim. Geceleri otobüs yolculuğu yapmayı tercih ediyorum. Bu sayede kalacak yer mevzusunu çözmüş oluyorsunuz : ) Otobüste nasıl uyunur? Konfor alanı dışında konfor alanı nasıl oluşturulur? Bununla ilgili de küçük tüyoların olduğu bir yazı ilerleyen zamanlarda gelecek.

Milano’dan 22.30 sularında başlayan yolculuğum ertesi sabah 7.45 sularında Roma Tiburtina Otobüs Terminali’nde sona erdi. Yola tek başına çıkıp yolda en az 1 Türk ile tanışmak gezilerimin olmazsa olmazımdır. Bu sefer 1 Brezilyalı ve 1 Türk ile tanışarak seyahatime bir tutam renk kattım diyebiliriz. Otobüste tanıştığım 2 güzel insan ile gezinin geriye kalan kısmını geçirdik. Sabah 8 gibi indiğimiz otobüs terminalinden öncelikle otellerimize yerleşmeyi tercih ettik. Zaten sırtımızdaki çantalar ile Haziran ayının kavurucu sıcağında gezmek mantıklı değildi. Benim otelim Kolezyum’a 15-20 dkka yürüme mesafesindeydi. Bu sebeple gezimin ilk durağı Kolezyum oldu.

İtalya’nın en önemli tarihî miraslarından biri olan Kolezyum veya diğer adıyla Flavianus Amfi Tiyatrosu. Kesinlikle Roma’nın en popüler yeri. Roma’nın sembolü olarak bilinen bu yapı zamanında gladyatörlerin dövüştüğü bir yermiş. Aşırı kalabalık oluşundan dolayı içeriye girmek için kuyruğu beklemek istemedik ve dışarıdan instagramlık fotoğraflarımızı çekip yolumuza devam ettik. Tanıştığım 2 gezgin ile tercihimiz çoğunlukla yürüyerek gezmek olsa da yürümeyi tercih etmek istemeyenler için metroyla Colosseo durağında inerek Kolezyum’a gelinebilir.

Kolezyum giriş ücreti 12€, sıra beklemeden girmeyi sağlayan super bilet ise 16€.

Kolezyum’un hemen dibinde yer alan tarihi yerleri gezmeye başladık. Tarih demişken Roma zaten başlı başına destansı bir tarih bildiğiniz gibi. Karşınıza sürekli antik yapılar çıkıyor. Tarih severlerin aşık olacağı bir şehir diyebilirim. Açıkçası gezi süresince yeter bu kadar tarih dediğim anlar oldu. Ama o anda sokağın bir kenarından duyulmaya başlayan müzik sesleri ile hemen fikrimi geri aldım. Bir de sokak sanatçıları.. Her birinin apayrı yeteneği var. Tek kelime ile muazzam.

Gelelim gezimizin devamına; Kolezyum’un hemen yanında bulunan Zafer Takı ve Roma Forumu ile gezimize devam ettik. Roma Forumu (Foro Romano), eskiden Roma’nın şehir merkezi konumundaymış, ticaretin, siyasi ve dini işlerin yönetildiği yermiş. Sonra Palatino Tepesi‘ne devam ettik. Bir sonraki durak ise Circus Maximus. Burası da antik bir hipodrummuş. Öğlen 12.30 gibi Kolezyum ile başladığımız rotamız 16.00 gibi acıkma molasına giriyor. Sabah check-in saatinden önce otele gittiğim için eşyalarımı bırakmıştım ama odama yerleşememiştim. Bu sebeple hem eşyalarımın güvenliğinden emin olmak (^^) hem de check-in için otele geri döndüm. İşlerimi hallettikten sonra internetteki yorumlara göre yakınımızdaki Pizza alabileceğimiz mekana karar verdik: Pizzeria Ostiense. Tam fiyatı şu an hatırlamamakla beraber genel olarak 2 gün boyunca yediğimiz dilim pizzaların fiyatı 3-5€ arasındaydı.

Ardından rotamızı Aşıklar Çeşmesi‘ne (la Fontana di Trevi) çevirdik. Rotaya doğru giderken Trajan Forumu (Foro di Traiano) olarak bilinen noktaya da uğradık. Burası imparatorluğun son meydanıymış. Ardından yürüyüşümüz Piazza Venezia yani Venedik Meydanı‘na kadar sürmüş oldu. Bu meydana vardığınızda devasal bir abide ile karşılaşıyorsunuz: Vittorio Emanuele II Abidesi. Bu abide İtalya’nın ilk kralı Vittorio Emanuele II için yaptırılmış. Romalılar bu anıtı sevmemiş ve ‘Roma’nın Takma Dişleri’ ‘Düğün Pastası’ gibi isimler ile buraya hitap etmişler. Romalıların aksine ben burayı bayağı sevdim 🙂 Merdivenlerinden yukarı çıktığınızda çok güzel bir Roma manzarası sizleri karşılıyor. Fotoğraf severler için birebir 😉

Meydandan devam ederek Via Del Corso isimli ünlü caddeye ilerliyoruz. Bu caddeye girdiğimizde sağ tarafımızda Aşıklar Çeşmesi (la Fontana di Trevi) yer alıyor. Çooook kalabalıktı çoook. İnternetteki fotoğraflara bakınca ben yanlış yere mi gittim dedim sonrası. Çünkü kalabalıktan yapıtın detaylarını inceleyemedim açıkçası. Ama Roma yılın her mevsimi kalabalık bir şehirmiş. Tabii şu an Korona sürecinde nasıldır bilemiyorum. İnanışa göre; çeşmeye arkanızı dönerek sağ elinizle sol omzunuz üzerinden para atar ve dilek dilerseniz hem dileğiniz kabul olurmuş hem de Roma’ya tekrar gelirmişsiniz. Denemedim 😛 Zaten denesem de kalabalıktan dolayı bence suya düşmezdi o para.

19.30 gibi Aşıklar Çeşmesi’nden ayrılıyor ve İspanyol Merdivenleri’ni (Piazza di Spagna) görmek üzere yürümeye devam ediyoruz. Tüm gün doymak bilmeyen Brezilyalı arkadaşımız bu sefer de dondurma alalım fikrini öne sürünce Gelato g Italino isimli ünlü dondurmacı dükkanından dondurma almaya niyet ediyoruz. İçeri girip fiyatları görünce fikrimizden vazgeçtik 🙂 20.00 gibi İspanyol Merdivenleri’nin olduğu alana vardık. Daha da kalabalık yer ömrü hayatımda yalnızca YTÜ yemekhanesinde gördüm arkadaşlar 😦 YTÜ’lü olanlar bilir orta bahçeye uzanan kuyrukları.. Şöyle ki, burası insanların buluşmak için kararlaştırdığı, merdivenlerde oturup bir şeyler yiyip içtiği bir alanmış. Biz de tam saatinde gittiğimizi düşünürsek kalabalık olması normal. Burayı daha sakin bulmak için bence sabah saatleri tercih edilebilir. Aynı şekilde bu fikrim Aşıklar Çeşmesi için de geçerli. Ama kesinlikle 2 yere de öğle vakti gitmeyin. Giderseniz şimdiden başınıza geçen güneşten ben sorumlu değilim 🙂 Gelelim İtalya’da İspanyol Merdiveni’nin neden bulunduğuna. o alanda İspanya Konsolosluğu yer aldığından meydanın ve merdivenlerin isim annesi olmuş diyebiliriz. Biz de merdivenlerde bir süre oturduk ve sabah 1€’ya aldığımız stok muzlarımızı yedik 🙂

Her gezi günün sonunda kaç km yürüdüğüme bakarım. 30 km yürüdüğümüz bir gün olmuş arkadaşlar. Bence 1 gün için gayet iyi 🙂 O zaman Roma’da 2.güne başlamak için dinlenme zamanı gelmiş. İspanyol Merdivenleri’nden otele yürüyemecek kadar yorulduğuma karar vererek metro kullandım. MEA olarak geçen kırmızı metroyla Spagna durağından binip Vittorio Emanuele durağında MEB1 metrosuna geçiş yaptım. MEB1 metrosuna Termini durağından binmiş oldum ve Piramide durağında indim. Otelim bu istasyona yaklaşık 450 m uzaklıkta. Ayrıca MEB1 metrosu şehirlerarası otobüs terminaline de gidiyor. Bu sebeple otelim hala en uygun fiyatlı oteller arasındaysa tercih edebilirsiniz.

2.günün planında ilk olarak dün gezemediğimiz Pantheon geliyor. Via Del Corso isimli ünlü caddenin sol tarafında yer alan bu meşhur tapınağı ücretsiz olarak gezebilirsiniz. Ama içeri girmek için biraz uzun beklemek zorunda kalacaksınız. Değer mi? Değer. Burası kralların, ressamların ve mimarların gömülü olduğu bir mezar yeri. Pantheon, betondan yapılan ve desteksiz olan dünyanın en büyük kubbesine sahip. Yapının kubbesi delik bir yapıda. Bu deliğin ismi Oculus. Güneşli günlerde kubbedeki bu delikten giren güneş penceresiz mahzeni aydınlatırken, yağmurlu günlerde bu kubbeden giren yağmur damlaları yerde bulunan minik deliklerden dışarı atılıyor. Gerçekten sıradan olmayan bu yapı görülmeden dönülmemesi gereken bir yer.

Pantheon’un ardından Roma sokaklarında bir süre akışına dolaşabilirsiniz. Vespa’lar ve Fiat 500’leri göreceğiniz dar sokaklar, filmlerdeki sahneleri anımsatabilir. Random dolaşırken Roma pazarına denk düşmeniz de mümkün, bizim gibi. Pazar içerisinde gezerek değişik tadımlar yapmanız münkün. Bazı pazarcılar ikram konusunda bonkör 🙂 Ek olarak, sonradan araştırınca öğrendim ki tesadüfen denk geldiğimiz bu pazarın orası Çiçek Tarlası yani Campo de Fiori olarak adlandırılıyormuş.

Ardından Piazza Navona’ya rotayı çevirdik. Bulunduğumuz konuma yakın oldukça ünlü bu meydanda 3 adet çeşme bulunuyor. Meydanda bulunan çeşmelerin en ünlüsü Bernini’nin yaptığı Dört Nehir Çeşmesi (Amerika’da Rio de la Plata, Avrupa’da Tuna, Asya’da Ganj, Afrika’da Nil Nehri). Meydanı etrafı kafeler ile dolu. Ayrıca kulağınızda müzik sesleri de eksilmiyor.

Buraya kadar hep Tiber Nehri’nin doğu yakasını gezdik. Gezimin devamı Dünya’nın en küçük ülkesi olan Vatikan. Vatikan’ı ayrı bir yazıda size anlatmak istiyorum. Şimdilik hikayeyi burada keselim. Yakında Vatikan ve gelecek diğer yazılar ile görüşmek üzere..

Sağlıklı ve gezili günleriniz olsun!

Deploy a Website based on Geographic Location with AWS CloudFront and Lambda@Edge

Bugün bir önceki yazıya takvime yapmak istediğim için tekrar klavyemin başına geçiyorum. Yakın zamanda paylaştığım “Ajandada Bugün: AWS CloudFront” yazımda CloudFront üzerine detaylıca konuşmuştuk. Bugün ise bir coğrafi konuma görre kişiselleştirdiğimiz bir website içeriğini nasıl CloudFront ve Lambda@Edge kullanarak deploy edebileceğimize bakalım istiyorum. Çaylar hazırsa haydi başlayalım 🐸


Gereksinimler:

Öncelikle bu demo için bir AWS hesabınız ve console erişiminiz olması gerektiğini belirtmek isterim. Sırayla gerçekleştireceğimiz adımlar şu şekilde:

1. S3 Bucket Oluşturma ve Statik İçerik Yükleme
2. Lambda@Edge Fonksiyonu Oluşturma
3. CloudFront Dağıtımı Oluşturma
4. CloudFront Dağıtımını Test Etme

Demo adımlarıyla başayalım öyleyse 👇🏻

Adımlar:
1. S3 Bucket Oluşturma ve Statik İçerik Yükleme
  1. AWS Management Console‘a giriş yapalım.
  2. S3 servisini açıp yeni bir bucket oluşturacağız.
    • Bucket Namekubikolog-demo-website
    • Region: Size en yakın bölgeyi seçin.

3. Bucket’ı oluşturduktan sonra, bucket’ın içine girelim ve Permissions sekmesine gidelim.

4. Bucket Policy eklememiz gerekiyor. Aşağıdaki gibi ekleyebilirsiniz.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::kubikolog-demo-website/*"
        }
    ]
}

5. Properties sekmesine gidelim ve Static website hosting bölümünde Use this bucket to host a website seçeneğini işaretleyelim

  • Index documentindex.html

6. Aşağıdaki içeriği bilgisayarınızda index.html olarak kaydedip ardından Upload sekmesine gidelim ve index.html adlı basit bir HTML dosyası yükleyelim.

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Geolocation Demo</title>
</head>
<body>
    <h1 id="greeting">Welcome!</h1>
    <p>This website uses CloudFront and Lambda@Edge to personalize content based on your location for kubikolog demo.</p>
</body>
</html>
2. Lambda@Edge Fonksiyonu Oluşturma
  1. AWS Management Console‘da Lambda servisini açalım.
  2. Create function butonuna tıklayıp aşağıdaki gibi kendinize göre kutuları doldurun.
    • Function nameGeoGreetingFunction
    • RuntimeNode.js 20.x
    • RoleCreate a new role with basic Lambda permissions

3. Fonksiyon oluşturulduktan sonra, aşağıdaki kodu Function code bölümüne yapıştıralım ve fonksiyonu kaydedelim.

exports.handler = async (event) => {
    const request = event.Records[0].cf.request;
    const response = event.Records[0].cf.response;
    const headers = request.headers;
    
    const country = headers['cloudfront-viewer-country'] ? headers['cloudfront-viewer-country'][0].value : 'unknown';

    let greeting = 'Welcome!';
    if (country === 'US') {
        greeting = 'Hello World!!';
    } else if (country === 'FR') {
        greeting = 'Bonjour de la France!';
    } else if (country === 'JP') {
        greeting = 'こんにちは、日本から!';
    }

    const modifiedResponse = {
        status: response.status,
        statusDescription: response.statusDescription,
        headers: response.headers,
        body: response.body.replace('<h1 id="greeting">Welcome!</h1>', `<h1 id="greeting">${greeting}</h1>`),
        bodyEncoding: 'text',
    };

    return modifiedResponse;
};
3. CloudFront Dağıtımı Oluşturma
  1. AWS Management Console‘da CloudFront servisini açalım.
  2. Create Distribution butonuna tıklayıp , Web seçeneğini seçelim ve devam edelim.
  3. Origin Settings bölümünde:
    • Origin Domain Name: S3 bucket adınızı seçin (kubikolog-demo-website.s3.amazonaws.com).
    • Origin Path: Boş bırakın.
    • Namekubikolog-geo-origin (varsayılan olarak gelir).
  4. Default Cache Behavior Settings bölümünde:
    • Viewer Protocol PolicyRedirect HTTP to HTTPS seçin.
    • Lambda Function AssociationsOrigin Response seçeneği altında, oluşturduğunuz Lambda fonksiyonunu ekleyin (GeoGreetingFunction).
  5. Distribution Settings bölümünde:
    • Price ClassUse Only North America and Europe (maliyeti düşük tutmak için).
    • Alternate Domain Names (CNAMEs): Boş bırakın (örneğinizi basit tutmak için).
    • SSL CertificateDefault CloudFront Certificate (TLS kullanımı için).
  6. Create Distribution butonuna tıklayıp kaydediyoruz.
4. CloudFront Dağıtımını Test Etme
  1. CloudFront dağıtımınızın durumunun Deployed olmasını bekleyin (Bu birkaç dakika sürebilir). Yanında deploying olarak yazıyor.
  2. Dağıtımın Domain Name‘ini kopyalayalım. (örneğin: d1234567890abcdef.cloudfront.net) ve bir web tarayıcısında bu domain name’i açalım.

Eğer her şey doğru yapılandırılmışsa, web sayfanız kullanıcıların coğrafi konumuna göre kişiselleştirilmiş bir mesaj gösterecektir. Örneğin, ABD’den erişen kullanıcılar “Hello World !!” mesajını görecektir.

Sonuç olarak; bu adımları tamamladığınızda, AWS CloudFront ve Lambda@Edge kullanarak coğrafi konuma göre kişiselleştirilmiş içerik sunan bir web uygulaması oluşturmuş olacaksınız. Bu demo, CloudFront’un Lambda@Edge ile entegrasyonunu ve bu kombinasyonun sağladığı yapıyı anlamamız daha da kolaylaştığını düşünüyorum.


Yazının sonuna doğru gelirken KubikFM’den bugün sizlere dinlerken her duyguya girdiğim bir şarkıyı armağan ediyorum 🐸🦋

“Biraz neşe biraz hüzün, biraz öyle biraz da böyle”


Ajandada Bugün: “AWS CloudFront”

Sıcak yaz günlerine giriş yaptığımız Haziran ayının ilk günlerinden herkese selamlar,
Bugün yakın zamanda katıldığımız AWS CloudFront Workshop’ununu referans alarak hazırladığım yazımı sizler ile paylaşmak istiyorum. Çayınız hazırsa haydi başlayalım 🐸


Günümüzde, web sitelerinin ve uygulamaların hızlı ve güvenilir bir şekilde erişilebilir olması giderek daha önemli hale geliyor. İnternet kullanıcıları, içeriklere saniyeler içinde erişmek istiyorlar ve bu da web geliştiricileri için büyük bir meydan okuma olabilir. İşte tam bu noktada AWS CloudFront gibi hizmetler, bu zorluğun üstesinden gelmek için tasarlanmış hizmetler olarak sahneyi süslüyor.

AWS CloudFront, Amazon Web Services tarafından sunulan bir CDN (Content Delivery Network) hizmetidir.

Peki CDN Nedir?

CDN (İçerik Dağıtım Ağı), web sitesi içeriğini en düşük ağ ve işlem gecikmesiyle, yani en hızlı şekilde, kullanıcılara ulaştırmak için coğrafi olarak farklı yerlerdeki sunucuları kullanır.

E-ticaret ve haber siteleri gibi pek çok web sitesi, sayfa yükleme sürelerini minimumda tutmak için CDN’den yararlanır. CDN, genellikle kullanıcılar arasında pek değişmeyen HTML, JavaScript, CSS, resim, video ve font dosyalarını sunar. Bu içerikler, asıl sunucu (origin) tarafından sağlanır ve CDN tarafından belirli bir süre için önbelleğe alınır. Bu süreden sonra, kullanıcı talepleri bu önbellekten karşılanır. Önbellek süresi sona erdiğinde, CDN kaynakları yenilemek için origin sunucusuna tekrar başvurur.

CDN sağlayıcıları, dünya genelinde çeşitli ülkelerde sunucular bulundurarak ağ gecikmelerini en aza indirir. Ayrıca, bu dağıtık sunucular, web sitesinin veri merkezinin yoğunluk yaşamasını da önler.


AWS CloudFront, web içeriğini hızlı ve güvenli bir şekilde kullanıcılara ulaştırmak için istemcilere en yakın Edge Location (kenar konumu) üzerinden dağıtır. Bu, bir web sitesine eriştiğinizde veya bir uygulamayı kullandığınızda, içeriklerin CloudFront’un dünya çapındaki ağı sayesinde size hızla iletilmesi anlamına gelir.

Bu hizmetin en güzel yanlarından biri, veri transfer hızlarıdır. CloudFront sayesinde, web içeriklerine daha hızlı erişir ve web uygulamaları daha hızlı yanıt verir. Ayrıca, bu hizmet kullanılarak web içeriklerini dağıtmak, sunucuların yükünü azaltır ve daha düşük bir maliyetle daha yüksek bir ölçeklenebilirlik sağlar. Böylece, kullanıcılar daha iyi bir deneyim yaşarken, işletmeler de daha verimli bir şekilde çalışabilir.

Bir diğer harika özellik ise, CloudFront’un diğer AWS hizmetleriyle entegre çalışabilmesidir. Örneğin, Amazon S3’te barındırılan bir web sitesi, CloudFront üzerinden kolayca dağıtılabilir. Ayrıca, AWS Lambda gibi diğer hizmetler de CloudFront ile kullanılabilir, bu da geliştiricilere daha fazla esneklik sağlar.

Sonuç olarak, AWS CloudFront, web içeriklerinin hızlı, güvenli ve ölçeklenebilir bir şekilde dağıtılmasını sağlayan harika bir CDN hizmetidir. Geliştiriciler için büyük bir yardımcı olan bu hizmet, kullanıcı deneyimini iyileştirirken işletmelere de daha iyi bir performans ve maliyet etkinliği sunar.

Cloud Front Terminoloji

Edge Locations: Bu, içeriğin önbelleğe alındığı ve ayrıca yazılabildiği konumdur.
Origin: Bu, CDN’nin dağıtacağı tüm dosyaların kaynağıdır. Başlangıç noktaları bir S3 Bucket, EC2 Bulut Sunucusu, Elastic Load Balancer veya Route53 olabilir
Distribution: Bu, Uç Konumları koleksiyonundan oluşan CDN’ye verilen addır.
Amazon S3 Transfer Acceleration: Son kullanıcılarınız ile bir S3 paketi arasında uzun mesafelerde hızlı, kolay ve güvenli dosya aktarımı sağlar.
Transfer Acceleration, Amazon Cloud Front’un küresel olarak dağıtılmış uç konumlarından yararlanır. Veriler bir uç konuma ulaştıkça, veriler optimize edilmiş bir ağ yolu üzerinden Amazon S3’e yönlendirilir

Lambda@Edge

Lambda@Edge, AWS Lambda’nın bir özelliğidir ve CloudFront’un Edge Location’larında çalışan işlevler oluşturmayı sağlar. Bu, CDN’nin Edge Location’larına yakın bir konumda kod çalıştırmanıza olanak tanır.

Lambda@Edge, dinamik içerik oluşturma, güvenlik denetimleri gerçekleştirme, önbellek yönetimi gibi çeşitli senaryolarda kullanılabilir. Örneğin, istemcilere özelleştirilmiş içerik sunmak, güvenlik duvarı kontrolleri uygulamak, isteğe bağlı olarak içerik sıkıştırma yapmak gibi işlevler Lambda@Edge ile gerçekleştirilebilir.

Bu özellik, CloudFront’un global ağı üzerindeki her bir Edge Location’da işlevsellik sağlar ve bu da içeriğin daha hızlı ve daha yakın kaynaklardan sunulmasını sağlar. Lambda@Edge, işlevleri Edge Location’larda çalıştırırken AWS Lambda’nın tüm özelliklerinden yararlanır, bu da güçlü ve ölçeklenebilir işlevselliklerin uygulanmasını mümkün kılar.

Özetle, Lambda@Edge, AWS Lambda kullanarak CloudFront’un Edge Location’larında çalışan işlevler oluşturmayı sağlar, bu da içerik dağıtımını daha hızlı, daha güvenli ve daha özelleştirilebilir hale getirir.

AWS Shield

AWS Shield, AWS tarafından sunulan bir DDoS (Dağıtılmış Hizmet Reddi) koruma hizmetidir. DDoS saldırıları, bir hizmete yoğun miktarda trafik göndererek, normal trafiği engelleyerek veya hizmeti kullanılamaz hale getirerek işletmeler için ciddi bir tehdit oluşturabilir. AWS Shield, bu tür saldırılara karşı koruma sağlar ve işletmelerin uygulamalarını ve altyapılarını güvenli bir şekilde korumasına yardımcı olur.

AWS Shield, iki farklı sürümde sunulmaktadır:

  1. AWS Shield Standard: AWS müşterilerine otomatik olarak sunulan ve temel DDoS koruması sağlayan ücretsiz bir hizmettir. AWS altyapısına yönelik en yaygın ve basit DDoS saldırılarını engeller. Bu, bir AWS hesabına otomatik olarak dahil edilir ve ek bir ücret talep etmez.
  2. AWS Shield Advanced: AWS müşterilerine gelişmiş DDoS koruması sağlayan bir ücretli hizmettir. Bu hizmet, geniş kapsamlı ve karmaşık DDoS saldırılarına karşı koruma sağlar. AWS Shield Advanced, saldırıları gerçek zamanlı olarak izler, otomatik saldırı hafifletme özelliklerine sahiptir ve uzman destek sağlar. Ayrıca, AWS Web Uygulama Firewall (WAF) gibi diğer güvenlik özellikleriyle entegre edilebilir.

AWS Shield, hem web siteleri hem de uygulamalar için önemli bir güvenlik katmanı sağlar. DDoS saldırılarına karşı koruma sağlamak için kullanıcılara kolaylık ve güvenlik sağlar, böylece işletmeler operasyonlarını kesintisiz bir şekilde sürdürebilirler.

Redis vS CloudFront

Redis ve CloudFront, farklı ihtiyaçlara ve kullanım senaryolarına yönelik olarak tasarlanmış farklı hizmetlerdir.

Redis: Redis, hafızada veri depolama ve önbellek yönetimi için kullanılan bir açık kaynaklı veritabanıdır. Özellikle dinamik içeriklerin önbelleğe alınması ve hızlı erişim için kullanılır. Örneğin, bir e-ticaret web sitesinde sıkça erişilen ürünlerin önbelleğe alınması için Redis tercih edilebilir. Bu sayede, ürün sayfalarının hızlı yüklenmesi sağlanabilir ve site performansı artırılabilir. Redis’in hafıza tabanlı veri depolama yapısı, yüksek performans ve düşük gecikme süreleri sunar.

CloudFront: CloudFront, statik ve dinamik içeriğin dağıtımı için kullanılan bir içerik dağıtım ağıdır. Bu hizmet, içeriği dünya çapındaki bir ağ üzerinden hızlı ve güvenli bir şekilde dağıtarak, kullanıcı deneyimini iyileştirir. Özellikle statik içeriklerin (örneğin, resimler, CSS dosyaları) daha hızlı yüklenmesini sağlamak için kullanılır. CloudFront, içeriği en yakın konumda bulunan edge location’lar aracılığıyla dağıtarak, yüksek hız ve düşük gecikme süreleri sunar. Böylece, web siteleri ve uygulamaları daha hızlı yanıt verir ve kullanıcılar için daha iyi bir deneyim sağlar.

Özetle, Redis ve CloudFront farklı amaçlar için kullanılan farklı hizmetlerdir. Redis, hafızada veri depolama ve önbellek yönetimi için kullanılan bir açık kaynaklı veritabanıdır. CloudFront ise, statik ve dinamik içeriğin dağıtımı için kullanılan bir içerik dağıtım ağıdır.


Yazının sonuna doğru gelirken geleneği bozmuyoruz ve KubikFM’in favori şarkılarından birini sizlere sunuyoruz dostlar 🐸

Ayrıca bir küçük mekan önerisi ile de günü kapamak istiyorum. Üniversite yıllarımdan beri severek takip ettiğim satılık dilek ağacı olan ama fiyatı dudak uçuklatan (zaten dilekleriniz de kabul olmuyor bu arada , denendi…… ), gündüzleri atölye akşamları konser eşliğinde çaykolik bir mekan önerisi yapmak istiyorum: TAHTASI EKSİKLER: ATÖLYE KAFASI. Son zamanlarda kahvaltı konserleri diye bişi de yapmaya başladılar. Eee gidin bence 😇

Mekanı çoktan keşfetmiş olanlar şarkıyla bağını anladı diye düşünüyor sizi Küçük Yılan ile başbaşa bırakıyorum 🐸


Referanslar:

👉🏻 https://aws.amazon.com/blogs/networking-and-content-delivery/amazon-s3-amazon-cloudfront-a-match-made-in-the-cloud/
👉🏻 https://crishantha.medium.com/aws-cloudfront-architecture-75d59e1df053
👉🏻 https://medium.com/@gokhansengun/cdn-nedir-ve-neden-kullan%C4%B1l%C4%B1r-71f6ffce6133
👉🏻 https://medium.com/@BerkayKulak/aws-cloudfront-detayl%C4%B1-anlat%C4%B1m-8babed1cb75f

S3 Migration from AWS to Huawei with Batch Operations

Selamlar dostlar,

Bugün sizlere TurkNet’te AWS S3’ten Huawei OBS’ye gerçekleştirdiğimiz migration işleminden bahsetmek istiyorum.

İşletmeler bazen farklı özelliklerden yararlanmak, maliyetleri optimize etmek veya düzenleyici gereksinimleri karşılamak için bu tarz dönüşümlere ihtiyaç duyabiliyor. Biz de bazı datalarımızı AWS S3’ten Huawei Object Storage Service’e (OBS) taşıyarak her iki platformdan da yararlanmak istiyoruz. Eğer sizin de AWS S3’ten başka bir ortama çoklu data taşıma işlemine ihtiyacınız var ise bu yazı ile bu işlemi nasıl daha hzılı otomatize ederek gerçekleştirebileceğinize bakabilirsiniz.

Öncelikle biraz AWS S3 ve Huawei OBS’den kısaca bahsetmek istiyorum.

AWS S3

Amazon Simple Storage Service (S3), endüstri lideri ölçeklenebilirlik, veri erişilebilirliği, güvenlik ve performans sunan yaygın olarak kullanılan bir nesne depolama hizmetidir. AWS S3, web üzerindeki herhangi bir yerden herhangi bir miktarda veri depolamak ve almak için tasarlanmıştır. Arşivlenmiş veriler için AWS, düşük maliyetli depolama çözümleri sunan S3 Glacier ve S3 Glacier Deep Archive hizmetlerini sunar.

Huawei OBS

Huawei Object Storage Service (OBS), güvenli, güvenilir ve maliyet etkin depolama çözümleri sunan bir bulut depolama hizmetidir. OBS, büyük ölçekli veri depolamayı destekler, diğer Huawei Cloud hizmetleri ile sorunsuz bir şekilde entegre olur ve güçlü veri koruma özellikleri sunar. Huawei’in bu yıl itibariyle Türkiye zone ununu da hizmete açması Huawei’nin Türkiye pazarında yerinin de önemini arttırmıştır.

S3 Migration from AWS to Huawei

Şimdi asıl konumuz migration işlemi üzerine konuşmaya başlayabiliriz. Burada S3 teki taşınacak objelerin storage classını kontrol ederek başlamamız gerekiyor. Çünkü eğer S3 Glacier veya S3 Glacier Deep Archive depolama sınıfında objeleriniz var ise doğrudan verilere erişmeniz mümkün değil. Öncelikle restore işlemi yapılarak objelerin erişilebilir olmasını sağlamamız gerekiyor. Amazon S3 ve veri depolama sınıfları ile ilgili daha detaylı bilgi için Ajandada Bugün: “Amazon s3” yazımı okuyabilirsiniz.

Restore with Batch Operations

👉🏻S3 Glacier Deep Archive depolama sınıfındaki bir objeyi taşımadan önce, veriyi geri çağırmanız (restore) gerekir. Bu işlem, veriyi daha erişilebilir bir duruma getirir. Restore işlemi saatler ila günler arasında sürebilir. S3 Glacier Deep Archive için bu süre genellikle 12 saatten 48 saate kadar uzadığını söyleyebilirim.

👉🏻Restore işlemi, S3 Glacier Deep Archive’deki objenin geçici bir kopyasını S3 Standard, S3 Standard-IA gibi daha erişilebilir bir depolama sınıfında oluşturur. Bu geçici kopya belirli bir süre (genellikle 1-15 gün arasında) boyunca erişilebilir olur. Bu süreyi siz ihtiyacınıza göre belirleyebiliyorsunuz. Tabi ki ücreti mükabilinde 🙂

👉🏻Geçici kopya erişilebilir olduktan sonra, S3 yönetim konsolu veye AWS CLI kullanarak bu objenin depolama sınıfını değiştirebilirsiniz. Bu işlem, objeyi kalıcı olarak istediğiniz başka bir S3 depolama sınıfına taşıyacaktır. Yani yukarıda belirttiğim belirli bir süre erişilebilir olma konusunu aşmış olacağız.

❗️ Ek bir bilgi olarak bu yapılan işlemlerde her bir restore işlemi sırasında veri geri çağırma ücreti uygulanıdığını belirtmek isterim. Ayrıca data erişilebilir olduktan sonra da yeni depolama sınıfına kopyalama işlemi de ekstra maaliyet olarak karşınıza çıkacaktır ve tüm bu api istekleri de ayrıca api isteği olarak maaliyet olarak gözükmektedir.

Şimdi gelelim fasulyenin faydalarına 🙂 Bu bahsettiğim adımları gerçekleştirdikten sonra artık objemizi istediğimi cloud providera taşınabilir hale getirmiş oluyoruz. Ama bir bucketınızda elbette 1-2 obje bulunmuyordur. Milyonlarca objenizin bulunduğu bucketlarda migration işlemi için önce bu restore&copy adımlarını her bir obje için gerçekleştirmeniz gerekecek. Tam bu noktada hayat kurtaran daha önce de bir yazımda konu aldığım S3 Batch Operations feature ı hayatımızı kolaylaştırıyor diyebilirim. Daha detaylı bilgi için dilerseniz Ajanda da Bugün: “AWS S3 Batch Operasyonları” ‘nı da okuyabilirsiniz. Bu feature ile restore işlemini , hatta dilersek copy işlemini bir job oluşturararak yapabiliriz.

Şimdi adım adım gelin bu behsettiğim işlemleri yapalım.

Restore İşlemi:

Bu işlemi manuel olarak obje obje gerçekleştirmek isterseniz Amazon S3 servisinde Bucket bölümüne giderek aşağıdaki gibi objeleri ne kadar süre restore un tutulacağını belirterek yapabilirsiniz👇🏻

Burada karşımızda iki tip geri alma şekli çıkıyor: Bulk retrieval, Standard retrieval. Bulk retrieval maaliyet olarak en düşük olan ama geri yükleme süresi standarda göre uzun olan seçenektir. Büyük bir arşiv veya veri yedeği geri yüklemek istediğimizde ve bu verilerin hemen erişilebilir olmasının gerekmediği durumlarda Bulk Retrieval seçerek ilerleyebiliriz. Bizim için de bu seçenek uygun gözüküyor. Bu işlem tamamlandıktan da sonra da restored copy süresi bitmeden datayı kopyalamamız gerekecek.

💥💥Şimdi gelelim bu işlemi S3 Batch Operations ile birçok parquet için tek seferde yapmaya💥💥

Öncelikle konsoldan S3 Batch Operations servisine gidelim. Burada create job diyerek ilerlememiz gerekiyor. Aşağıdaki gibi açılan pencereden işlem yapılacak parquet lerin hepsini CSV formatında kaydederek yüklememiz gerek.

Burada parquet listemiz kabarık ise işin rengi hoş olmuyor tabiki. Bizim de çok sayıda taşınacak klasör klasör ayrılmış archive datamız olduğu için burada bu işlemi yapacak bir manifest generator kullandık. Github linkindan bu minik yazılımı indirerek kolaylıkla manifest.csv dosyasını oluşturacağız. Tüm Batch operasyonlarınız için bu generatoru kullanabilirsiniz.

git clone https://github.com/kubrakus/amazon-s3-manifest-generator-for-batch-operations

cd amazon-s3-manifest-generator-for-batch-operations
npm install

Manifest Generator kurulduktan sonra örnekteki gibi bucketınıza ait manifest.csv dosyasını oluşturabilirsiniz. Burada folder bazlı da bu manifest içeriğini üretmek mümkün.

Not: CLI üzerinden AWS’e erişmek bucketlerınızı görüntüleyebilmek için AWS CLI ‘yı indirmeniz gerekiyor.

Şimdi oluşturduğumuz manifest dosyamızı bucket içerisine upload edelim.

aws s3 cp manifest.csv s3://kubikolog-demo/

Artık Batch Operation job ı create etmek için gereksinimlerimizi tamamladık. Önceki görselde belirttiğim browse S3 butonuna tıklayarak aşağıdaki resimde görüldüğü şekilde manifest.csv dosyamızı seçerek ilerleyeceğiz.

Bir sonraki adımda karşımıza hangi operasyonu gerçekleştirmek istediğimiz çıkıyor ve restore seçerek devam ediyoruz. Manuel restore işleminde de tanımladığımız restored copy nin saklanma süresi ve restore tipini seçerek ilerletiyoruz.

Bir sonraki adımda işlem tamamlandığında raporu oluşturacağı adresi tanıplayıp ilgili IAM role ü seçerek jobı create edelim.

Not: Burada gördüğünüz üzere “BatchOperationsRestore” role ü seçilmiştir. Bu işlem için bu role ekli değil ise önce IAM panelinden eklenmesi gerekmektedir. Tüm bucketlar için ya da seçili bucketlar için işlem izni verilerek ilerleyebilirsiniz.

Evet, artık jobımız hazır. ✅

Jobun çalışması için sob bir adımımız kaldı. Job a tıklayarak run diyoruz ve artık restore operasyonumuz başladı.

Artık objelere girip baktığınızda açıklama kısmında restore in progress ifadesini göreceksiniz. Tamamlandıktan sonra da expire date i yazıyor olacak.

Bu işlem datalarınızın boyutuna göre biraz sürecek. Tamamlandıktan sonra hem job ekranından hem obje içerisinden restore un tamamlandığını kontrol edebilirsiniz.

Ardından artık dataları copy işlemine geçebiliriz.

Copy İşlemi:

Aşağıdaki komut ile kubikolog-demo bucket’ındaki demo1 klasöründeki tüm dosyaları ve alt klasörleri kubikolog-demo-std bucket’ındaki demo1 klasörüne kopyalayacağız. Kopyalanan tüm dosyalar hedef bucket’ta STANDARD depolama sınıfında saklanacak.

aws s3 cp s3://kubikolog-demo/demo1/ s3://kubikolog-demo-std/demo1 --storage-class STANDARD --recursive --force-glacier-transfer

Tüm bu işlemden sonra artık datalarımızı migration işlemi için standart storage class tipinde kaydetmiş olduk.

Şimdi migration işlemini gerçekleştirebiliriz. 🧬

Migration İşlemi:

Huawei Cloud konsoluna giriş giriş yaptıktan sonra Object Storage Service’ini açalım. Burada migration işlemi için oluşturulmuş bir feature yer almaktadır.

❗️Migration işlemi için hem Amazon S3 tarafına hem de Huawei OBS tarafına erişim için access key ve secret bilgisine ihtiyaç duyulmaktadır. Bu bilgileri girerek ve source – destination bucketları seçerek migration işlemini ilerletebiliriz.

Bir sonraki ekranda çeşitli parametrelerin özelleştirilebildiği sekme yer alıyor. Source yapılandırmasında, taşıma yöntemini (dosya/klasör, nesne listesi, nesne adı öneki veya URL listesi), source bucket’ı ve taşınacak nesneleri seçebilirsiniz. Ayrıca, nesne metadata’sını taşıma ve seçmeli taşıma yapma seçenekleri bulunur. Hedef yapılandırmasında veri şifreleme, belirli bir prefix ve depolama sınıfı ayarları yapılabilir.

Migration taskını başlattığında tasks sekmesinden statüsünü kontrol edebilirsiniz. Tamamlandığnda taskın aşağıdaki completed olduğunu görebilirsiniz.

Bu arada Migration Tasks ve Migration Task Groups diye iki seçenek bulunmaktadır. “Migration Tasks”, tekil veri taşıma işlemlerini temsil ederken, “Migration Task Groups” ise bu işlemleri organize etmek ve yönetmek için bir araya getirilmiş görev gruplarını ifade eder. Tekil migration görevleri belirli veri setlerinin veya nesnelerin kaynaktan hedefe taşınmasını sağlarken, task grupları benzer görevleri bir araya getirerek taşıma sürecini daha sistemli ve etkin hale getirir. Bu yapı, büyük ölçekli veri taşıma operasyonlarını daha yönetilebilir ve organize edilebilir kılar.

İki Cloud provider arası data migration işlemini başarıyla tamamladık dostlar ✅

Şimdi sizleri KübikFM’ playlistinden dinlerken kanepede şekerleme yapmalık şarkısıyla başbaşa bırakıyor, iyi uykular diliyorum 🐸

Ajandada Bugün: “AWS S3 Batch Operasyonları”

Herkese selamlar dostlar,

Bu blog yazısında yine AWS’in kıymetli üyesi AWS S3 Batch Operasyonları üzerine konuşuyor olacağız. Biraz teorik inceledikten sonra bir demo ile de iş hayatında işlerimizi kolaylaştırdığı yönüne değinmeyi, planlıyorum.

Amazon S3 Batch Operations Nedir?

Amazon S3 Batch Operations, S3 nesneleri üzerinde toplu işlemler gerçekleştirmek için kullanılan bir hizmettir. Bu hizmet ile, aynı anda çok sayıda nesneye yönelik işlem yapabilirsiniz. S3 Batch Operations, nesne kopyalama, nesne etiketleme, ACL güncelleme, Lambda işlevleri çalıştırma ve daha fazlasını içerir.

S3 Batch Operations Kullanım Adımları
1. Create a Job

S3 Batch Operations kullanmaya başlamak için ilk adım, bbir job create etmektir. Bu iş, belirli bir işlemi belirli bir nesne seti üzerinde gerçekleştirecektir. Create job süreci şu adımları içerir:

  • Manifest Dosyası Oluşturma: İşlem yapmak istediğimiz nesnelerin listesini içeren bir manifest dosyası oluşturmamız gerekiyor. Bu dosya, genellikle CSV formatında olur ve işlem yapılacak nesnelerin anahtarlarını içerir.
  • İş Tanımı: AWS Management Console, AWS CLI veya SDK kullanarak iş tanımını yapmak gerekiyor. Bu tanımda, işin manifest dosyası, işlem türü ve diğer gerekli parametreler yer alır.
2. Job Configuration

Job create ederken, hangi tür işlemi gerçekleştirmek istediğinizi seçmeniz gerekir. S3 Batch Operations tarafından desteklenen işlem türleri şunlardır:

  1. Copy (Kopyala):
    • Bu operasyon, her bir nesneyi belirtilen hedefe kopyalar. Bu, verilerinizi farklı bir konuma veya yedekleme için başka bir klasöre taşımanın etkili bir yoludur.
  2. Invoke AWS Lambda function (AWS Lambda işlevini çağır):
    • AWS Lambda, sunucusuz bir hesaplama hizmetidir ve bu operasyon ile her bir nesne üzerinde belirli bir Lambda işlevini çalıştırabilirsiniz. Örneğin, veri dönüştürme veya analiz işlemleri için kullanabilirsiniz.
  3. Replace all object tags (Tüm nesne etiketlerini değiştir):
    • Bu operasyon, her nesnedeki mevcut etiketleri yenileriyle değiştirir. Veri yönetimi ve organizasyonu için etiketler kullanışlıdır.
  4. Delete all object tags (Tüm nesne etiketlerini sil):
    • Bu operasyon, tüm nesne etiketlerini siler. Etiketlerin temizlenmesi gereken durumlarda kullanılır.
  5. Replace access control list (ACL) (Erişim kontrol listesini değiştir):
    • Nesnelerin erişim kontrol listelerini (ACL) değiştirir. Bu, nesnelere kimlerin erişebileceğini belirlemek için kullanılır.
  6. Restore (Geri yükle):
    • Arşivlenmiş nesneler için geri yükleme talepleri başlatır. Bu, Amazon S3 Glacier gibi arşivleme çözümlerinde saklanan nesnelerin geri yüklenmesi için kullanılır.
  7. Object Lock retention (Nesne Kilidi muhafazası):
    • Nesnelerin belirli bir süre boyunca silinmesini veya üzerine yazılmasını önler. Bu, veri bütünlüğünü ve güvenliğini sağlamak için kullanılır.
  8. Object Lock legal hold (Nesne Kilidi yasal tutma):
    • Yasal nedenlerle nesnelerin silinmesini veya üzerine yazılmasını önler. Bu, yasal uyumluluk ve düzenleyici gereklilikler için kritik olabilir.
  9. Replicate (Çoğalt):
    • Nesneleri çoğaltma işlemi gerçekleştirir. Bu operasyon, çoğaltma yapılandırmasında belirtilen hedeflere nesneleri kopyalar. Manifest dosyası, çoğaltma işlemleri için sürüm kimliği içermelidir.
3. Start and Monitor the Job

Job ı başlattıktan sonra, S3 Batch Operations işlemi başlatır ve tüm nesneler üzerinde belirttiğiniz işlemi gerçekleştirir. İşin ilerlemesini AWS Management Console, AWS CLI veya SDK üzerinden izleyebilirsiniz.

4. Completion and Reporting

Job tamamlandığında, S3 Batch Operations işin sonuçlarını ve olası hataları içeren bir rapor oluşturur. Bu rapor, işin başarıyla tamamlanan ve başarısız olan kısımlarını detaylı bir şekilde gösterir.


Amazon S3 Batch Operations Kullanım Örnekleri
  • Veri Taşıma ve Yedekleme: “Copy” operasyonu ile büyük veri setlerinizi farklı bir konuma veya yedekleme amaçlı başka bir klasöre taşıyabilirsiniz.
  • Veri Dönüşümü ve İşleme: “Invoke AWS Lambda function” operasyonu ile nesneler üzerinde özel veri dönüşümü veya analiz işlemleri gerçekleştirebilirsiniz.
  • Veri Yönetimi: “Replace all object tags” ve “Delete all object tags” operasyonları ile nesnelerinizin etiketlerini güncelleyebilir veya temizleyebilirsiniz.
  • Güvenlik ve Erişim Kontrolü: “Replace access control list (ACL)” operasyonu ile nesnelere erişimi düzenleyebilir ve kontrol edebilirsiniz.
  • Arşivleme ve Geri Yükleme: “Restore” operasyonu ile Amazon S3 Glacier gibi arşivleme çözümlerinde saklanan nesnelerinizi geri yükleyebilirsiniz.
  • Veri Koruma: “Object Lock retention” ve “Object Lock legal hold” operasyonları ile nesnelerin silinmesini veya üzerine yazılmasını önleyerek veri koruma sağlayabilirsiniz.

Tüm bu söylediklerimizi toparlayarak bize sağladığı avantajlar üzerine konuşacak olursak;

Kolay yönetim imkanı sunarak tek bir iş tanımı ile milyonlarca nesne üzerinde işlem yapabilme olanağı sağlar. Aynı zamanda büyük veri kümeleri üzerinde hızlı ve verimli işlemler gerçekleştirme yeteneği ile ölçeklenebilirlik sunar. Nesne kopyalama, etiketleme, ACL güncelleme gibi çeşitli işlemleri destekleyerek kullanıcıya geniş bir işlem yelpazesi sunar. Bununla birlikte, işin sonuçlarını ve olası hataları detaylı bir şekilde raporlayarak kullanıcıya değerli geri bildirimler sunar.

Şimdi gelin birlikte bir demo ile bu konuştuklarımızı pekiştirelim.

Demo: AWS S3 Batch Operasyonları ile Dosya Yedekleme

Bu demoda AWS S3 Batch Operasyonları’nın kullanımını göstermek için basit bir dosya yedekleme senaryosu yapacağız. Demoya başlamadan önce ihtiyacınız olan gereksinimler bir AWS hesabı ve bu hesabı gerekli IAM yetkilendirilmesine sahip olması gerekir. (AWSBatchFullAccess ve AmazonS3FullAccess rolleri atanmış olmalıdır.)

Adımlar:

1. AWS Konsolu’nda Batch Operasyon Rolü Oluşturma:

  • AWS Yönetim Konsolu’na giriş yapın.
  • IAM hizmetine gidin ve “Roller” bölümüne tıklayın.
  • “Rol Oluştur” düğmesine tıklayın.
  • “AWS hizmetlerini seç” düğmesine tıklayın ve “S3” yazarak S3 hizmetini seçin.
  • “S3 Batch operasyonları” kullanabilecek izinler vermek için uygun politikayı ekleyin ve rolü oluşturun.

2. Batch Operasyonu Tanımlama:

  • AWS Konsolu’nda, S3 hizmetine gidin ve “Batch Operasyonları” bölümüne tıklayın.
  • “Operasyon Tanımla” düğmesine tıklayın.
  • Bir ad ve açıklama belirleyin.
  • İşlem tipini seçin (örneğin, “Kopyalama”).
  • Kaynak ve hedef konumları belirtin (örneğin, kaynak S3 bucket’i ve hedef S3 bucket’i).

3. Review

  • Batch Operasyonları sayfasında, oluşturduğunuz operasyonu seçin , tamamlandı raporunun kaydedileceği bucket adresini belirtin ve ve “Gönder” düğmesine tıklayın.

4. Monitoring:

Batch Operasyonları sayfasında, gönderdiğiniz işlemi bulun. Durumu ve ilerlemesi hakkında bilgi alın.Tamamlandığında, başarılı bir şekilde tamamlandığında job oluştururken seçtiğin path de report dosyasını bulabilirsiniz. Results şeklinde bir dosya oluştuğunu aşağıdaki gibi görebilirsiniz.

Bu minik demoyu da tamamladığımıza göre artık son sözleri söyleme vakti. KübikFM dinleyicilerine bugün 2024 eurovision favori şarkısını takdim ediyor. Tabi bu klibin çekilmesindeki en büyük emekçi kameraman abiye de bir teşekkürü borç bilirim.

Esen kalınız efenim 🐸

Ajandada Bugün: “Amazon S3”

Merhaba dostlar,

Bugün bulut teknolojilerinden biri olan Amazon S3 hakkında biraz sohbet edelim istiyorum. Amazon S3, yani Simple Storage Service, bulut depolama dünyasında gerçek bir kahraman. Duymayan yoktur eminim. Bu minik yazıda Amazon S3 kullanırken, bir bucket açarken nelere dikkat etmeli? Nasıl bütçe dostu oluruz? , bunlar üzerine konuşalım istiyorum.

Amazon S3 Nedir?

Öncelikle, duymayan yoktur dedim ama yine de açıklamak boynumun borcu 🙂 Amazon S3 bulut depolama hizmeti, verilerinizi çevrimiçi olarak saklamanızı ve yönetmenizi sağlar. Öyle sıkıntıları, sarmalayan kabloları, yer kaplayan sunucuları unutabiliriz. Amazon S3 ile verilerinizi dünya çapında dağıtık bir şekilde güvenli bir şekilde saklayabilirsiniz. Ayrıca, bu hizmet, ölçeklenebilir, güvenilir ve düşük maliyetli bir depolama çözümü sunar.

Amazon S3’ün Özellikleri
  1. Esneklik: Amazon S3, farklı veri türleri için esnek depolama seçenekleri sunar. Verilerinizi metin dosyalarından video ve fotoğraflara kadar her şeyi depolayabilirsiniz.
  2. Yüksek Dayanıklılık: Amazon S3, verilerinizi birden fazla bölgede replike ederek %99.999999999 (11 Nines!) dayanıklılık sağlar. Evet, yanlış duymadınız, bu muazzam bir rakam! İddialılar :)))
  3. Kolay Kullanım: Amazon S3’nin basit ve sezgisel bir kullanıcı arayüzü vardır. Verilerinizi yüklemek, yönetmek ve paylaşmak saniyeler içinde yapılabilir.
  4. Güvenlik: Amazon S3, verilerinizi güvende tutmak için güçlü şifreleme ve erişim kontrolü sağlar. Gönül rahatlığıyla verilerinizi saklayabilirsiniz.
  5. Ölçeklenebilirlik: İş büyüdükçe, Amazon S3 de sizinle birlikte büyür. İhtiyacınız olduğunda depolama kapasitesini kolayca artırabilirsiniz.
  6. Maliyet Etkinliği: Amazon S3, kullanıldığı kadar ödersiniz. Gereksiz yere para harcamanıza gerek yok. Verilerinizin depolama maliyetleri oldukça rekabetçidir.
Amazon S3 Kullanım Senaryoları
  • Web Sitesi Barındırma: Web sitenizin statik içeriğini Amazon S3’de depolayabilir ve dağıtabilirsiniz.
  • Yedekleme ve Arşivleme: Önemli verilerinizi Amazon S3’te güvenle saklayabilirsiniz.
  • Veri Analizi ve İşleme: Büyük veri analizi ve işleme için Amazon S3 verilerini kullanabilirsiniz.
  • Mobil Uygulama Depolama: Mobil uygulamalarınızın dosyalarını Amazon S3’te saklayabilirsiniz.

Amazon S3 kullanırken bir bucket oluştururken aslında birkaç önemli noktaya dikkat etmemiz gerekiyor. İlk olarak, bucket adı seçerken kafa karışıklığına neden olmayacak ve diğer kullanıcılar tarafından zaten kullanılmayan bir isim seçmeye özen göstermek önemli. Ayrıca, verilerinizin nerede depolanacağını da düşünmelisiniz. Eğer verilerinizin belirli bir coğrafi bölgede tutulması gerekiyorsa, bu gereksinimi göz önünde bulundurmalısınız.

Bucket oluştururken, kimin neye erişebileceğini de iyi ayarlamak önemlidir. Verilerinize sadece yetkili kişilerin ulaşmasını sağlamak için gerekli erişim kontrollerini ayarlamak gerekebilir. Bir de dosyalarınızın birden fazla sürümünü saklamak isteyebilirsiniz. Bu durumda versiyonlama özelliğini etkinleştirebilirsiniz. Öyle ki, eğer yanlışlıkla bir dosyayı silerseniz veya bir hata yaparsanız, geri dönebileceğiniz bir yedekleme bulunur.

Şimdi, bütçe dostu olmanın püf noktalarına gelelim. Verilerinizin saklanma şekline göre uygun depolama sınıflarını seçmek çok önemlidir. Mesela, verileriniz sık sık erişilen ve değiştirilen türden değilse, daha uygun maliyetli depolama seçeneklerini düşünebilirsiniz. Bir de Amazon S3’nin yaşam döngüsü politikaları var ki, bu sayede eski verileri otomatik olarak daha düşük maliyetli depolama sınıflarına taşıyabilir veya gereksiz verileri temizleyebilirsiniz. Böylece hem maliyetleri düşürmüş olursunuz hem de verimliliği artırırsınız.

Amazon S3 Depolama Sınıfları

Amazon S3 (Simple Storage Service) çeşitli kullanım senaryolarına uygun farklı depolama sınıfları sunar. Her bir depolama sınıfı maliyet, dayanıklılık, erişim süresi ve veri erişim sıklığı gibi farklı özelliklere sahiptir. İşte Amazon S3 depolama sınıflarının detayları:

  1. S3 Standard (Genel Amaçlı)
    Kullanım Senaryosu: Sık erişilen veriler için uygundur.
    Dayanıklılık: %99.999999999 (11 Nines) dayanıklılık.
    Erişim Süresi: Düşük gecikme süresi ve yüksek throughput.;
    Maliyet: Diğer sınıflara göre daha yüksek.
  2. S3 Intelligent-Tiering (Akıllı Katmanlama)
    Kullanım Senaryosu: Erişim düzenleri değişken olan veriler için uygundur.
    Dayanıklılık: %99.999999999 (11 Nines) dayanıklılık.
    Erişim Süresi: Milisaniye düzeyinde erişim süresi.
    Maliyet: Sıklıkla erişilen veriler için S3 Standard maliyetinde, seyrek erişilen veriler için ise daha düşük maliyet sunar. Kullanım izleme ücreti vardır.
  3. S3 Standard-IA (Seyrek Erişim)
    Kullanım Senaryosu: Sık erişilmeyen, ancak gerektiğinde hızla erişilmesi gereken veriler için uygundur.
    Dayanıklılık: %99.999999999 (11 Nines) dayanıklılık.
    Erişim Süresi: Milisaniye düzeyinde erişim süresi.
    Maliyet: Depolama maliyeti daha düşük, ancak veri erişim başına ücretlendirme vardır.
  4. S3 One Zone-IA (Tek Bölge Seyrek Erişim)
    Kullanım Senaryosu: Tek bir AWS Bölgesinde depolanması kabul edilebilir, sık erişilmeyen veriler için uygundur.
    Dayanıklılık: %99.999999999 (11 Nines) dayanıklılık, ancak veri tek bir bölgede depolanır.
    Erişim Süresi: Milisaniye düzeyinde erişim süresi.
    Maliyet: S3 Standard-IA’dan daha düşük maliyet.
  5. S3 Glacier (Düşük Maliyetli Arşivleme)
    Kullanım Senaryosu: Uzun vadeli yedekleme ve arşivleme için uygundur.
    Dayanıklılık: %99.999999999 (11 Nines) dayanıklılık.
    Erişim Süresi: Dakikalar ila saatler arasında erişim süresi.
    Maliyet: Çok düşük depolama maliyeti, veri geri çağırma ücreti vardır.
  6. S3 Glacier Deep Archive (Daha Düşük Maliyetli Arşivleme)
    Kullanım Senaryosu: Yıllarca erişilmesi beklenmeyen veriler için uygundur.
    Dayanıklılık: %99.999999999 (11 Nines) dayanıklılık.
    Erişim Süresi: Saatler ila günler arasında erişim süresi.
    Maliyet: En düşük depolama maliyeti, veri geri çağırma ücreti vardır.

Bu depolama sınıfları arasında seçim yaparken verilerin erişim sıklığını, erişim hızını ve maliyet gereksinimlerinizi göz önünde bulundurmanız önemlidir. Her sınıfın kendi avantajları ve kullanım alanları bulunmaktadır.

Örneğin, Amazon S3 Glacier ve S3 Glacier Deep Archive depolama sınıflarında bulunan arşiv verileri, bir restore işlemi gerçekleştirilmeden önce doğrudan okunamazlar. Bu depolama sınıfları, uzun vadeli veri arşivleme ve yedekleme için tasarlanmıştır ve normalde nadiren veya hiç erişilmezler.

S3 Glacier ve S3 Glacier Deep Archive’deki verilere erişmek istendiğinde, öncelikle verinin geri çağırılması (restore) işlemi gerçekleştirilmelidir. Geri çağırma işlemi, veriyi daha erişilebilir bir depolama sınıfına geçici olarak kopyalar ve bu kopya üzerinden veriye erişim sağlanabilir hale gelir. Geri çağırma işlemi tamamlandıktan sonra, veri normal S3 depolama sınıflarından birine taşınabilir veya işlenebilir.

Bu yaklaşım, maliyetleri düşük tutarken veri dayanıklılığını sağlar ve nadiren erişilen verilerin depolanmasını daha ekonomik hale getirir. Ancak, bu tür verilere erişim gerektiğinde, geri çağırma işlemlerinin zaman alabileceğini ve maliyetlere yol açabileceğini unutmamak önemlidir.


Umarım bu yazı, Amazon S3 hakkında size daha fazla bilgi sağlamıştır. Şimdi, sıra biraz keyif zamanında. KübikFM’in bugünkü şarkısı evin prensesi, kardeşim için geliyor. Onun repertuarından bir şarkıyı sizlerin beğenisine sunuyoruz 👸🏼

Esen kalın efenim 🐸

AWS Community Day 2024 – Backstage

Herkese Merhaba,

Geçtiğimiz günlerde gerçekleşen ve bence yılın en win win etkinliği diyebileceğimiz AWS Community Day ardından neler dinledik, neler anlatıldı üzerine bu yazıda konuşalım istiyorum.

Öncelikle şunu belirtmeliyim ki bulut dünyasına, AI temelli gelişen trend teknolojilere, Serverless uygulamalara ilgi duyan herkes için kıymetli bir etkinlik oldu. Alanında uzman birçok konuşmacı tecrübelerini paylaşarak bizlere ufuk oldu.

Açılış ve keynote dan sonra 2 paralel oturum ile gün boyu süren etkinlik, stantlardaki interaktif aktiviteler ile de günün hem öğrenerek hem eğlenerek geçmesini sağladı. Öyle ki kayıt sırasında verilen sürpriz çekilişe katılım için stant stant damga toplandığımız formdan kahoot oyunlarına, kelime avından oyuncak kapma makinesine birçok hem teknolojik hem nostaljik aktiviteler ile keyifli anlar yaşadık. Günün sonunda 1 go, 1 kubernetes amigurumi oyuncağına sahip olmuş biri olarak günün en win win insanlarından biri olduğumu söyleyebilirim. Tabi ki tek başıma kazanmadım. Biz bir ekibiz 🙂 TurkNet olarak hem çekilişlerde hem aktivitelerde günün en win win katılımcılarıydık diyebilirim. Aşağıda o güzel anlardan kalan hatıra fotoğraflarımızı da görebilirsiniz 🙂

Açılış konuşmasında, bulut bilişim alanındaki son trendler, yenilikler ve AWS’nin vizyonu hakkında genel bir bakış sunuldu. Bulut teknolojilerinin iş dünyasında nasıl dönüştürücü etkiler yarattığı ve gelecekte hangi teknolojilerin öne çıkacağı tartışıldı.

Potansiyel yeni mühendis adayı: Gen AI

AWS Ürün Yönetimi Direktörü Massimo Re Ferre keynote konuşmasında Generative AI ‘ın gelecekteki potansiyeli üzerine yaptığı konuşmasında hepimiz eminim son zamanlarda kendi kendine sorduğu soruları sesli olarak tüm katılımcılara yöneltti. Generative AI, günlük yaşantımızda temel bir gelişme mi yoksa geçici bir teknolojik trend mi? Generative AI asistanları ne derece faydalı olabilir? Bizi daha üretken hale getirebilirler mi? Onlara güvenebilir miyiz? Yoksa biz mühendislerin yerine mi geçecekler? Sunumunda bununla ilgili belirttiği bir sözü sizlerle paylaşarak aslında tüm bu sorulara cevap niteliği olduğunu düşünüyorum.

Buna ek olarak devamında dinlediğimiz birçok sunumda ağırlıklı olarak AI üzerine konuşuldu. AWS’te AI Orkestrasyonu üzerine gerçekleştirilen bir sunumda Generative AI ekosistemine adapte olmanın güçlükleri üzerine uzun uzun konuşuldu. Bunun üzerine geliştirilen EPAM AI DIAL platformundan bahsedildi. İncelemek isterseniz linkini de buraya bırakmış olayım.

Gün boyu dinlediğimiz sunumlarda vurgulanan bir diğer trend konu Serverless! Yan Cui konuşmasında serverless mimarisinden bahsederek AWS Lambda hakkında detaylıca anlatım yaptı. Lambda, function as a service olarak işlev sağlamasından dolayı AWS’in popüler hizmetlerinden biri. Bununla beraber sunumda CloudWatch’a değinen Yan Cui, AWS Lambda ve birçok AWS hizmetinin performansını ve sağlığını izleyebileceğimizi, metrikleri toplayıp alarm notificationları oluşturabileceğimiz üzerine konuşmasına devam etti. Özetle; Serverless mimari, AWS Lambda ve CloudWatch birlikte kullanıldığında, uygulamaların hızlı bir şekilde geliştirilmesini, maliyetlerin düşürülmesini ve operasyonel yükün azaltılmasını sağlamasıyla ön plana çıktığını bizlere aktarmış oldu.

Use Lambda functions to transform data, NOT transport data

Bununla beraber bir başka sunumda Serverless mimari ile kurgulanmış PostNL projesini dinledik. PostNL, Hollanda genelinde 300.000’den fazla eşyanın konumunu, hareketini ve kullanımını izleyebilen bir uygulama. Bunu başarabilmek için uygulama üzerinde dakikada milyonlarca güncellemeler, işlemler yapılması lazım. Bu işlemler Serverless Event-Driven Architecture ile sürekli değişime tabi şekilde kurgulanmış. Bu devasa iletim hattının nasıl tasarlandığını birinci ağızdan dinlemiş olduk. Burada aslında Serverless ile bu kadar kapsamlı bir projenin bile nasıl güvenilir ve ölçeklenebilir olduğunu görüyoruz.

Son sessionda ise yine Serverless konu başlığı altında başlayan sunum ile aslında başarısızlıkların nasıl bir öğrenme fırsatına dönüşebildiğini dinledik. Hem etkinliğin hem de yazımın sonuna doğru gelirken son sessiondan hoşuma giden birkaç satır ile sözlerimi noktalamak istiyorum.

Amazon CTO’su Dr. Werner Vogels ‘in da söylediği gibi: “Everything fails, all the time.”

AWS Community Day Türkiye 2024, bizlere teknik bilgi sağlamanın yanı sıra birçok alanında uzman kişilerle tanışma fırsatını sundu. Emeği geçen organizasyon ekibi Cloud Türkiye’ye, güzel hediyeleri ve aktiviteleri için sponsorlarına ayrıca teşekkür etmek isterim.

Öyleyse bu tarz etkinlikler artarak devam etsin diyor, geceye KübikFM’ den kariyer dolu hayatlarımıza mola şarkısı bırakıyorum 🐸

Ceph Storage Notlarım {5/5}

Merhaba , öncelikle serinin son yazısını aylar sonra paylaşıyor olduğum için siz sevgili Ceph sever okurlardan özür dileyerek başlamak istiyorum. Bugün planladığım gibi RBD, CephFS ve RGW üzerine konuşacağız.

Ceph’in temel bileşenleri arasında Ceph Cluster, RADOS Block Device (RBD), Ceph File System (CephFS) ve Ceph Object Gateway (RADOSGW) bulunur.

Öyleyse RBD ile başlayalım.

RADOS Block Device (RBD)

RBD (RADOS Block Device), Ceph depolama çözümünde kullanılan bir blok depolama özelliğidir. RBD, SAN (Storage Area Network) gibi geleneksel blok depolama çözümlerini simüle eder, ancak Ceph’in dağıtık, ölçeklenebilir ve yüksek performanslı yapısal avantajlarından yararlanır.

RBD, sanal makinelerin disk depolaması için idealdir. Sanallaştırma ortamlarında RBD kullanarak sanal makinelerinize yüksek performanslı ve esnek bir blok depolama çözümü sağlayabilirsiniz.

RBD, veritabanlarının depolama gereksinimlerini karşılamak için de kullanılabilir. Özellikle veritabanlarında yüksek performans, yedekleme, veri replikasyonu ve veri bütünlüğü gibi ihtiyaçların olduğu durumlarda RBD tercih edilebilir.

Ayrıca RBD, verilerin güvenli bir şekilde yedeklenmesi için kullanılabilir. RBD blok cihazları oluşturarak verilerinizi düzenli aralıklarla yedekleyebilir ve gerektiğinde bu yedekleri kullanarak veri kurtarma süreçlerini kolaylaştırabilirsiniz.

Bununla beraber büyük ölçekli veri depolama gereksinimlerini karşılamak için uygundur. Yüksek performans, ölçeklenebilirlik ve veri tutarlılığı gibi özellikleri sayesinde RBD, bulut depolama platformları ve büyük veri analizi uygulamaları için tercih edilen bir seçenektir.

RBD, blok cihazlarının anlık görüntülerinin (snapshot) alınmasına olanak tanır. Snapshot’lar, belirli bir zamandaki blok cihazı durumunun kopyasını almak için kullanılır ve veri geri alma veya kopyalama işlemlerinde kullanışlıdır. Ayrıca RVD klonlama da yapabiliyorsunuz. Klonlama, RBD, mevcut bir blok cihazının kopyasını oluşturarak yeni blok cihazlarının hızlı bir şekilde oluşturulmasına olanak tanır. Bu, test ve geliştirme ortamlarında çabuk bir şekilde yeni bloklar oluşturmanızı sağlar.

RBD, kullanım alanları açısından oldukça esnektir. Yukarıda bir şekilde haberdar olduğum kullanım alanlarını sizler ile paylaştım. İhtiyaçlarınıza ve kullanım senaryolarınıza bağlı olarak RBD’yi daha farklı şekillerde kullanabileceğinizi de belirtmek isterim.

Gelelim Ceph Cluster’da RBD kullanımını pratiğe dökmeye

Ceph üzerinde bir RBD havuzunu etkinleştirmek isterseniz, aşağıdaki komutları kullanabilirsiniz:

$ ceph osd pool create <pool-name>
$ ceph osd pool application enable <pool-name> rbd
$ rbd pool init -p <pool-name>

Bu komutlar, “rbd” adında bir RBD poolu oluşturacak ve RBD’nin kullanımını etkinleştirecektir. Ayrıca aşağıdaki komutlar, RBD pooluyla çalışırken kullanışlı olabilir.

rbd ls: Tüm RBD görüntülerini listeler.

rbd info <image-name>: Belirli bir RBD görüntüsü hakkında ayrıntılı bilgiler sağlar.

rbd create <gimage-name> --size <size>: Yeni bir RBD görüntüsü oluşturur.

rbd clone <source-image-name> <target-image>: Varolan bir RBD görüntüsünden yeni bir klon oluşturur.

rbd resize <image-name> --size <new-size>: Bir RBD görüntüsünün boyutunu değiştirir.

rbd snap create <image-name>@<snap-name>: Bir RBD görüntüsünün anlık görüntüsünü oluşturur.

rbd snap ls <image-name>: Bir RBD görüntüsüne ait tüm anlık görüntüleri listeler.

rbd snap rollback <image-name>@<snap-name>: Bir RBD görüntüsünü belirli bir anlık görüntüye geri döndürür.

rbd snap remove <image-name>@<snap-name>: Bir RBD görüntüsünden belirli bir anlık görüntüyü siler.

RBD ile ilgili fayda sağlayacağını düşündüğüm bilgileri sizler ile paylaştım. Bu alan deniz derya. Daha detaylı bilgiler için Ceph’in dökümantasyonlarına başvurabilirsiniz. Kolaylık diliyor, CephFS ile yola devam ediyorum.


Ceph File System (CephFS)

Ceph File System (CephFS), Ceph’in dağıtık bir dosya sistemi sunan bileşeni olarak karşımıza çıkar. CephFS, kullanıcılara yüksek performans, dayanıklılık ve ölçeklenebilirlik sağlayan bir dosya sistemi çözümüdür. Ayrıca POSIX uyumluluğuyla dikkat çeker, bu da geleneksel dosya sistemi arabirimlerini kullanabilmenizi sağlar.

CephFS, otomatik veri replikasyonu, ayrıştırma, veri kopyalama, çoklu düğüm desteği ve kotalandırma gibi özellikler sunar. Bu özellikler sayesinde, CephFS kullanıcıları büyük miktarda veriyi yönetebilir ve kullanıcı taleplerine hızlı ve güvenilir yanıtlar verebilir. Örneğin, büyük veri analizi, cloud-native uygulamalar, yüksek performanslı hesaplama, arşivleme ve veri paylaşımı gibi senaryolarda tercih edilebilir.

CephFS’i etkinleştirmek ve yapılandırmak için belirli adımlar izlenmelidir. Ceph cluster’ınızı kurduktan ve yapılandırdıktan sonra, metadata server’ı (MDS) etkinleştirmeniz gerekmektedir. MDS, CephFS’in metadata’nın saklanması ve dosya sistemi işlemlerinin yönetilmesiyle ilgilenir. MDS’yi başlatarak ve CephFS’i mount ederek CephFS’i kullanabilirsiniz

CephFS’i etkinleştirmek için gereken yapılandırmadan bahsetmek istiyorum. Ama öncesinde hazır konusu geçmişken MDS bileşeni hakkında kısaca konuşalım.

Metadata Server (MDS)

Metadata Server (MDS), CephFS’in çalışması için gereken bir bileşendir. MDS, CephFS’in metadata’nın saklanması ve dosya sistemi işlemlerinin yönetilmesiyle ilgilenir. Ceph cluster’ında bir veya daha fazla MDS bulunabilir.

MDS, dosya sistemi operasyonlarını desteklerken, kullanıcıların geleneksel dosya sistemi arabirimlerini kullanabilmesini sağlar. POSIX uyumluluğu sayesinde, mevcut uygulamaların ve araçların CephFS üzerinde çalıştırılması kolaylaşır.

MDS’nin çalışması, CephFS’in doğru ve güvenilir bir şekilde çalışmasını sağlar. MDS, dosya sistemi taleplerini işler, dosya ve dizin metadata’sını yönetir ve dosya sistemi işlemlerini düzenler. Böylece, kullanıcılar CephFS üzerinde dosyaları yönetebilir, paylaşabilir ve erişebilirler.

CephFS’in etkinleştirilmesi için bir MDS’nin konfigürasyonu ve çalıştırılması gerekmektedir. MDS, CephFS’in kullanımı için önemli bir bileşen olarak görev yapar. Nitekim Ceph clusterınızda MDS bileşeninde sorun olması durumda CephFS kullanan tüm diskleriniz bu durumdan etkilenecektir. Örneğin MDS serverın requestlere dönüşte yavaşlık yaşanıyor ise sizin CephFS disklerinizde r/w işlemlerinde gecikmeler yaşanır ya da r/w işlemini hiç yapamaz duruma gelebilirsiniz. Bu yüzden MDS önemli diyor, kaldığımız yerden CephFS’i yapılandırma adımlarından devam ediyorum 😊

CephFS’i etkinleştirmek ve yapılandırmak için Ceph poolunda belirli adımlar izlenmelidir. Ceph Cluster’ınızı kurdunuz ve yapılandırdınız varsıyorum. Ceph cluster bağlantılarınız da tam ise aşağıdan devam ediyoruz.

Haydı CephFS’i etkinleştirelim.

  1. CephFs için 2 adet pool oluşturun. (Data pool ve metadata pool)
    $ ceph osd pool create <data_pool> $ ceph osd pool create <matadata_pool> 
  2. Data ve meta poolu oluşturulduktan sonra, dosya sistemini oluşturmak için ceph fs new komutunu aşağıdaki gibi kullanın,
    $ ceph fs new <fs_name> <metadata_pool> <data_pool> 
  3. MDS’yi oluşturmak için aşağıdaki komutu kullanın. Bu komut, CephFS için yeni bir Metadata Server düğümü oluşturur ve bu düğümün nasıl çalışacağını ve nerede depolama yapacağını belirtir.
    $ ceph mds create <fs_name> --data <metadata_pool> 
    • <fs_name>: Önceden belirttiğiniz Ceph FS adını kullanın.
    • <metadata_pool>: Metadata havuzunu belirtin.
  4. MDS’nin çalıştığından emin olmak için aşağıdaki komutu kullanabilirsiniz.
    $ ceph mds stat 

    Bu komut, MDS’lerin durumunu ve çalışma durumunu gösterecektir.

  5. Ceph FS’i mount etmek için bir hedef dizin oluşturun:
    $ sudo mkdir /mnt/<mount_point> 
    • <mount_point>: Ceph FS’in mount edileceği hedef dizin adını belirtin.
  6. Ceph FS’i mount etmek için aşağıdaki komutu kullanın:

    sudo mount -t ceph <ceph-monitors>:6789:/ <mount_point> -o name=admin,secret=<admin_key>
    
    • <ceph-monitors>: Ceph monitorlerin adresini belirtin.
    • <mount_point>: Önceden oluşturduğunuz hedef dizin adını belirtin.
    • <admin_key>: Ceph admin anahtarını belirtin.

Bu adımları takip ederek, Ceph FS’i etkinleştirebilir ve kullanabilirsiniz. Unutmayın, komutlarda belirtilen parametreleri kendi yapılandırmanıza ve gereksinimlerinize göre değiştirmeniz gerekmektedir.

CephFS’i etkinleştirmekten bahsettik, peki ya kaldırmamız gerekirse? Aşağıdaki prosedürü izleyerek kaldırılması mümkündür sevgili ceph sever okurlar 🙂

$ ceph fs set <fs-name> down true
$ ceph fs rm <fs-name> --yes-i-really-mean-it

Son olarak CephFS ile çalışırken faydalı olabilecek bazı komutları sizler ile paylaşmak istiyorum.

ceph fs ls: Tüm CephFS dosya sistemlerini listeler.

ceph fs status: CephFS’in genel durumunu gösterir.

ceph fs set <fs_name> max_mds <count>: Belirli bir CephFS için maksimum Metadata Server (MDS) sayısını ayarlar.

ceph mds stat: Tüm Metadata Server (MDS) durumunu gösterir.

rados --pool=<metadata_pool> df: Metadata poolunun kullanım durumunu gösterir.

rados --pool=<data_pool> df: Data poolunun kullanım durumunu gösterir.

ceph fs df: CephFS’nin disk kullanımını izlemek ve depolama durumunu kontrol etmek için kullanılır.

Bu komutlar, CephFS ile ilgili temel işlemleri gerçekleştirmenize yardımcı olacaktır. O zaman son bileşenimize geçme vakte 👇🏻

RADOS Gateway (RGW)

RADOS Gateway (RGW), Ceph’in dağıtılmış bir nesne depolama servisidir. RGW, Amazon S3 ve OpenStack Swift gibi nesne depolama arabirimleri üzerinden erişilebilen ölçeklenebilir bir nesne depolama çözümü sunar.

RGW, nesneleri dağıtık bir şekilde depolamak için RADOS (Reliable Autonomic Distributed Object Store) ile entegre çalışır. RADOS, Ceph’in temel dağıtılmış depolama sistemidir ve RGW, RADOS üzerinde nesneleri depolamak ve yönetmek için bir arayüz sağlar.

RGW, dosyaları, metaverileri ve yapılandırma ayarlarını RADOS üzerinde depolar. Bu sayede RGW, yüksek performans, yüksek ölçeklenebilirlik ve yüksek kullanılabilirlik sunar.

RADOS Gateway (RGW) yapılandırması için aşağıdaki adımları takip edebilirsiniz:

  • RGW bileşenini etkinleştirmek öncelikle aşağıdaki örnekteki gibi bir YAML file oluşturmalısınız.
service_type: rgw
service_name: <rgw_service_name>
placement:
  count: 2
  hosts:
  - node01
  - node02
spec:
  rgw_frontend_port: 8080
  rgw_realm: <realm_name>
  rgw_zone: <zone_name>
  ssl: true
  rgw_frontend_ssl_certificate: |
    -----BEGIN PRIVATE KEY-----
    ...........................
    -----END PRIVATE KEY----- 
    -----BEGIN CERTIFICATE----- 
    ...........................
    -----END CERTIFICATE-----
  networks:
    - x.x.x.0/24
  • YAML file hazır olduktan sonra aşağıdakş şekilde apply edebilirsiniz.
    $ ceph orch apply -i rgw-service.yaml
  • RGW’nin başarıyla etkinleştirildiğini doğrulamak için aşağıdaki komutu kullanın.
    $ ceph orch ps 
    Komut sonuçları arasında RGW’nin çalıştığını görmelisiniz.
  • RGW’nin yeniden başlatılmasını sağlamanız gerekirse aşağıdaki komutu kullanabilirsiniz.
    $ ceph orch restart <rgw-service-name> 
  • Serviste bir konfigürasyon değişikliği yaptığınızda aşağıdaki komu ile servisi redeploy edebilirsiniz.
    $ ceph orch redeploy <rgw-service-name> 

RADOS Gateway (RGW) kullanırken faydalı olabileceğini düşündüğüm diğer komutları aşağıda bulabilirsiniz:

radosgw-admin user create --uid=<user_id> --display-name="<display_name>": Yeni bir RGW kullanıcısı oluşturur.

radosgw-admin bucket list --uid=<user_id>: Belirli bir kullanıcının tüm bucketlarını listeler.
NOT: “Bucket,” genellikle nesne depolama sistemlerinde, dosyaların ve verilerin saklandığı birimler olarak kullanılan terimdir.

radosgw-admin bucket stats --bucket=<bucket_name>: Belirli bir bucketın durumunu gösterir.

radosgw-admin bucket rm --bucket=<bucket_name> [--purge-objects]: Belirli bir bucketı siler.
‼️ Dikkat: “–purge-objects” flagi ile birlikte kullanıldığında buckettaki tüm nesneleri de siler.

radosgw-admin object rm --bucket=<bucket_name> --object=<object_key>: Belirli bir buckettaki bir nesneyi siler.

radosgw-admin user stats --uid=<user_id>: Belirli bir kullanıcının statüsünü gösterir.

radosgw-admin user modify --uid=<user_id> --max-buckets=<bucket_limit>: Bir kullanıcının maksimum bucket sayısını değiştirir.

radosgw-admin sync status: Veri senkronizasyon durumunu kontrol eder.

Bu komutlar, RGW’nin yönetimi ve kullanımı sırasında fayda sağlayabilen işlemleri gerçekleştirmenize yardımcı olacaktır diye düşünüyorum. Bu komutlarla beraber yazımın sonuna gelmiş bulunuyorum. Ayrıca serinin de son yazısını yazmış oldum. Bundan sonrası bir süre Ceph ile vedalaşıp merak ettiğim diğer teknolojileri konuşacağız. Sadece merak ettiklerim 🐤


O zaman klasiği bozmuyoruz; KübikFM’in bu geceki parçası gönüllerin bir olduğu eski dostlara gelsin. 🐸

Şipşak Sinop

2023’ün ilk günlerinde max verimli bir gezinin notlarını sizler ile paylaşmak istiyorum. Sabahın aydınlanmayan saatinde (04.00)’te gözümü açamayarak vardığım Sinop’u konuşacağız bugün. Öncelikle bir yaz günü tekrar gitmek istediğim şehir olarak tanıtmak istiyorum size Sinop’u. Peki kış günü neler mi yapılabilir? Gelin gezelim hadi.

1.İlk durak; Sohbeti hoş esnafı ve kahvaltısıyla Erfelek

Sinop otogar ile Erfelek ilçesi yaklaşık 20-25 dakika sürüyor. Sabah 08.00 itibariyle dolmuşlar başlıyormuş ya da bir bilene sorarak aynı istikametten giden bir şehirlerarası otobüsü de hedefe gidiş için tercih edebilirsiniz.

Otogar-Erfelek dolmuş ücreti: 20 TL (Ocak 2023)

Güne güzel bir kahvaltı ve hoş esnaf sohbeti için kesinlikle “Öztürk Restaurant” ‘a gitmelisiniz ve işletme sahibi Selahattin amca ile tanışmalısınız 🙂 Ardından Erfelek Tatlıca Şelaleri’ni görmek için yola devam edebilirsiniz. Yalnız şu sıralar bakımda olduğundan ne yazık ki tek bir şelaleyi görme imkanımız oldu. Normalde 28 ayrı şelale bulunuyor ve gerçekten Sinop’ta en merak ettiğim yerdi diyebilirim. Erfelek – Tatlıca Şelaleleri arası 20-25 dakika. Buraya toplu taşıma bulunmuyor. Taksi ile ya da kendi aracınız ile gitmek gerekiyor. Yolu dar ve virajlı, yer yer yer de selden kalma çökükler var, haberiniz olsun.

Objektifimden kareler sizlerle 👇

2. Sinop Merkez / Görülemeyen Cezaevi

Tatlıca Şelaleri’nin ardından Erfelek’ten merkeze doğru dolmuş ile 20-25 dkkalık bir yolculuk yapıyoruz tekrardan. Yolculuğun en güzel yanı sağdaki camların da soldaki camların da deniz görmesi 🙂 Merkezde yapılacaklar arasında şüphesiz ki Tarihi Sinop Cezaevi’ni görmek. Ancak tüm kırmızı ışıklar bize denk geldi 😦 Ne yazık ki burası da bakımdaymış. Ama cezaevinin denize yakınlığını görünce biraz Sinop’u gezince Sabahattin Ali’nin Dışarda deli dalgalar, gelir duvarları yalar. “Beni bu sesler oyalar, aldırma gönül aldırma…” sözleri ayrı bir anlam kazandı. Sabahattin Ali’nin izinden Cezaevine bakmak için tıklayabilirsiniz.

3. Mantıııı 🤭

Sahil boyunca biraz yürüdükten sonrası sıralı dizilmiş çay bahçelerinden birine oturarak kısa bir mola verip devamında nereye gideceğimizi planladık. Öğle yemeğine, akşam yemeği doyuruculuğunda olan, tabi ki Sinop mantıcısına gittik. Yine hemen merkezde, sahilden 200m içeride olan “Örnek Sinop Mantı Evi” tercihimiz oldu. Kesinlikle tavsiye edilir. Ama posiyon bayağı dolu dolu geliyor, bitirmekte güçlük çekebilirsiniz, bilginize 🙂

Yemek sonrası birkaç hediyelik eşya dükkanını gezerek küçük anılar kutusuna yenilerini ekleyerek yola devam ediyoruz.

4. Akliman ve Hamsilos Koyu

Sıradaki durağımız ise huzur dolu iki yer. Merkezden Akliman’a giden dolmuşlar ile 20 dakika da Akliman’a ulaşabilirsiniz.

Sinop Merkez – Akliman Dolmuş Ücreti : 13 TL (Öğrenci, Ocak 2023)

Son durakta dolmuştan inerek teknelerin kenarından sahil boyunca inekler eşiğinde bir yürüyüş yolu sizleri bekliyor. Yürüöeyi seviyorsanız yaklaşık 25-30 yürüyerek Hamsilos Koyu’na varabilirsiniz. Burası gerçekten haftasonu sandalyeleri alıp kafa dinlemelik bir alandı. Mesire alanı da bulunuyor, ailecek de gelip keyifli vakit geçirebilirsiniz.

Kadrajımdan bazı kareler sizlerle 👇

5. Premseslere özel Patentli Tatlı

Son olarak dönüş otobüsüme biraz daha zaman kalması sebebiyle merkeze geri dönüp biraz midemizde açılan boşluğu doldurmak için yeni rota oluşturalım dedik. Sadece Şen Pastanesi’nde bulabileceğiniz, öyle ki patenti de alınmış “Prenses” tatlısını denemek üzere gurmelik testine çıktık. Tatlı için canga tadı aldım diyebilirim. Midenizde yer kalırsa denemeden dönmeyin. Bu arada nokuldan konuşmadık. O da çok meşhurmuş burada, biz mide fesatı geçirmekten korkup yemedik açıkçası. Ama şu an su satırları yazarken neden paket yapıp yanımda getirmediğimin pişmanlığını yaşıyorum. Aklımda kalacağına midemde kalsın diye boşuna dememişler 🙂

Mini Sinop gezimizin sonuna doğru gelirken Sinop halkını, esnafını çok sevdiğimi tekrar dile getirmek isterim. Tekrar gitmek isteyeceğim Şehirler listesine eklendin Sinop, görüşmek üzere 🙋‍♀️

O zaman klasiğimiz ile noktalayalım. KübikFM’in bu geceki şarkısı akışına bırakan hayatlara gelsin.


🐸Bonus Fotiler🐸


Ceph Storage Notlarım {4/5}

Merhabalar, bugünkü yazımda Ceph Backend üzerine konuşalım istiyorum. Backend dediğimizde 2 terimi duyuyoruz: BlueStore, FileStore

BlueStore

BlueStore, Ceph için yeni nesil depolama uygulamasıdır diyebiliriz.. Nesne depolama için bir ham blok cihazıyla doğrudan etkileşime girer ve FileStore’un sahip olduğu bir dizi kısıtlamayı ortadan kaldırır.

Nasıl çalışıyor diye incelersek,

BlueStore doğrudan altta yatan blok cihazıyla çalışır ve dahili meta verileri korumak için RocksDB anahtar-değer veritabanını yerleştirir. BlueFS, RocksDB’nin üzerinde “dosyalar” depolamasına izin vermek için arabirim benzeri minimum dosya sistemi uygular ve aynı ham aygıtı posta BlueStore ile paylaşır.

FileStore

FileStore, nesneleri bir blok aygıtın üzerindeki bir dosya sistemi yardımıyla depolar. Red Hat Ceph Storage dosya sistemi olarak XFS kullanıyor. .

BlueStore ve FileStore arasındaki farklara bakacak olursak,

  1. En önemli farkın POSIX uyumlu bir dosya sisteminin kullanılmamasıdır diyebiliriz. Veri artık dosya sistemine değil raw olarak blok device’a yazılmakta.
  2. Bununla beraber yukarıdaki diyagramlarda gözüktüğü üzere metadata verinin tutulması için FileStore LevelDB kullanırken BlueStore RocksDB kullanıyor. RocksDB için de BlueFS isminde dosya sistemi tasarlanmış.
  3. BlueStore ile beraber data sıkıştırma desteği gelmiştir. Bu özelliği aşağıdaki komut ile kullanabiliriz.
$ ceph osd pool set <pool name> compression_mode <mode type>

Compression mode için olası değerler şunlardır:
none: compress never (Default is none)
passive: compress if hinted COMPRESSIBLE
aggressive: compress unless hinted INCOMPRESSIBLE
force: compress always

4. Filestore da diske yazılan verinin bozulup bozulmadığını pahalı bir operasyon ila takip ediliyormuş. Bluestore’da ile checksum desteği gelmiş.

Daha detaylı anlatım için şöyle aşağıya Red Hat’in videosunu da bırakayım.

Gelecek yazıda , serinin son yazısında, RBD, RGW ve CephFS’ in detaylarına bakarak kapanış yapmayı planlıyorum.

Sözlerimi noktalarken bugün (3 Aralık) okyanuslarda gezinen Albatros kuşunun doğum gününü kutlamak isterim. Öyleyse KubikFM’in bu geceki şarkısı da hediyemiz olsun. Evet, doğum günlerinin klasiği “Paramparça” Müslüm Baba’nın sesiyle sizlerle 🐸

Esen kalın efenim :)))